[00:41:43] jdlrobson: https://phabricator.wikimedia.org/T150248 is a known issue when you use OAuth via mobile and need to log in in the process [00:42:02] well, known as in "no one looked into it yet but several users complained" [00:42:10] maybe it's not Phabricator-specific [20:33:06] mdholloway: groom? [20:33:16] dbrant: 1:1, be there shortly [21:43:52] bearND: hey [21:44:54] jdlrobson: hi [21:46:37] so i just finished the last patch to process edits in the new trending service [https://gerrit.wikimedia.org/r/323239]. Right now the endpoint will surface ALL pages which have more than 6 edits AND have had activity in the last 40 minutes AND the first edit was seen within the last day AND have an edit speed of 0.1 edits per minute [21:47:24] annoyingly i cant detect reverts or new page creations [21:48:03] next sprint/week ill want to make sure i surface what the apps need... [https://phabricator.wikimedia.org/T145572] [21:48:28] do you think your team would have bandwidth to hydrate the responses with the information you need? https://phabricator.wikimedia.org/T150186 [21:48:53] I guess the new page creation by itself could be eventually negligible. The reverts would be interesting, though. [21:49:08] Yeh the reverts are unforunate [21:49:17] as i was using those in my trend algorithm [21:50:31] If you mean hydrating with summary data that's something that comes from RESTBase itself. [21:50:58] Or are you talking about adding the $merge property which should point to the summary endpoint? [21:51:15] bearND: right now all the trending API will give you is all the internals of the trending API [21:51:26] im not sure what you need - but that's all up for grabs now [21:52:08] right now trending gives you edits,anonEdits,from,updated,id,title, contributor information [21:52:22] i suspect we dont want/need to surface contributor information in the api response [21:54:08] I agree, we could skip the contributor info. Are anonEdits included in edits? What's the 'from' property? [21:55:25] So, I guess what you're after is stripping out unneeded info from the response, add summary data, and update spec.yaml if needed [21:56:30] bearND: so does your team have bandwidth? [21:56:45] i think it makes more sense for you to define what the output looks like [21:57:01] and for me to focus on making it sorted in such a fashion that the most interesting stuff comes first [21:57:07] Are you talking about the Android team? [21:57:13] As far as I understand it the iOS team would pick this one up first [21:58:39] bearND: one of the apps teams yes. i figured coreyfloyd is still getting up to speed with restbase so you may need to help. [21:58:51] I think I can help with the definition of it, in conjunction with the iOS team. [22:00:27] Will you be around if we have questions? Some of the properties may need clarification. [22:11:11] when? [22:11:26] We can talk async on the tickets. I'll leave a note. [22:22:52] async sounds good. Thanks. I'm leaning towards a simple format for the first couple of release, similar to what we have for the most_read endpoint. Summary stuff definitely, but the I think number of edits and some sort of timestamp could be useful, too. We can add things to it later if needed, of course. [23:32:07] dr0ptp4kt: in hangout