Hi all -
Max Semenik, now on Search & Discovery (he's been working on geo stuff for a while), spoke with me earlier today about transferring Reading-oriented extension components / API endpoints off his plate. I'll add the bullet points to the Etherpad for the recurring APIs/Services meeting instance tomorrow.
* API action=mobileview : the apps are heavy users of this endpoint.
* pageimages extension: Max noted that the algorithm needs improvement for targeting the "best" image.
* featuredfeeds extension (RSS/Atom)
* TextExtracts is still an open question. Max said he can maintain it in maintenance mode, if necessary. But if there's interest in Reading taking over future work on this, that would be even better. Max noted the persistence of the results is an area for improvement. Incidentally, some people have been communicating about this stuff today.
Thanks. -Adam
It's great to see this written down. I'd assumed that the Mobile Web *teams* were now responsible for maintaining those extensions and had been triaging bugs that landed in the mediawiki-extension-MobileFrontend and mobile-web projects as such.
Max: would you be up for a doing a techmosis – a recored presentation – covering all of those features? Specifically, I'd like to hear the areas that need improving.
–Sam
On Mon, May 11, 2015 at 9:12 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
Max Semenik, now on Search & Discovery (he's been working on geo stuff for a while), spoke with me earlier today about transferring Reading-oriented extension components / API endpoints off his plate. I'll add the bullet points to the Etherpad for the recurring APIs/Services meeting instance tomorrow.
API action=mobileview : the apps are heavy users of this endpoint.
pageimages extension: Max noted that the algorithm needs improvement for
targeting the "best" image.
featuredfeeds extension (RSS/Atom)
TextExtracts is still an open question. Max said he can maintain it in
maintenance mode, if necessary. But if there's interest in Reading taking over future work on this, that would be even better. Max noted the persistence of the results is an area for improvement. Incidentally, some people have been communicating about this stuff today.
Thanks. -Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I have the same question as Sam, are we officially supposed to be doing this type of work internally?
If so, Do we have a services engineer for the reading team? Or if not, do we have an open rec?
it would be nice to have a resource dedicated for this work (we are developing a rendering service for apps as well) preferably embedded in the reading team since we have so many service needs.
It would be nice to lock these things down while the reorg is still "flexible".
On Tuesday, May 12, 2015, Sam Smith samsmith@wikimedia.org wrote:
It's great to see this written down. I'd assumed that the Mobile Web *teams* were now responsible for maintaining those extensions and had been triaging bugs that landed in the mediawiki-extension-MobileFrontend and mobile-web projects as such.
Max: would you be up for a doing a techmosis – a recored presentation – covering all of those features? Specifically, I'd like to hear the areas that need improving.
–Sam
On Mon, May 11, 2015 at 9:12 PM, Adam Baso <abaso@wikimedia.org javascript:_e(%7B%7D,'cvml','abaso@wikimedia.org');> wrote:
Hi all -
Max Semenik, now on Search & Discovery (he's been working on geo stuff for a while), spoke with me earlier today about transferring Reading-oriented extension components / API endpoints off his plate. I'll add the bullet points to the Etherpad for the recurring APIs/Services meeting instance tomorrow.
API action=mobileview : the apps are heavy users of this endpoint.
pageimages extension: Max noted that the algorithm needs improvement
for targeting the "best" image.
featuredfeeds extension (RSS/Atom)
TextExtracts is still an open question. Max said he can maintain it in
maintenance mode, if necessary. But if there's interest in Reading taking over future work on this, that would be even better. Max noted the persistence of the results is an area for improvement. Incidentally, some people have been communicating about this stuff today.
Thanks. -Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Mobile-l@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/mobile-l
I'll be following up on a separate message.
On Wed, May 13, 2015 at 8:39 AM, Corey Floyd cfloyd@wikimedia.org wrote:
I have the same question as Sam, are we officially supposed to be doing this type of work internally?
If so, Do we have a services engineer for the reading team? Or if not, do we have an open rec?
it would be nice to have a resource dedicated for this work (we are developing a rendering service for apps as well) preferably embedded in the reading team since we have so many service needs.
It would be nice to lock these things down while the reorg is still "flexible".
On Tuesday, May 12, 2015, Sam Smith samsmith@wikimedia.org wrote:
It's great to see this written down. I'd assumed that the Mobile Web *teams* were now responsible for maintaining those extensions and had been triaging bugs that landed in the mediawiki-extension-MobileFrontend and mobile-web projects as such.
Max: would you be up for a doing a techmosis – a recored presentation – covering all of those features? Specifically, I'd like to hear the areas that need improving.
–Sam
On Mon, May 11, 2015 at 9:12 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
Max Semenik, now on Search & Discovery (he's been working on geo stuff for a while), spoke with me earlier today about transferring Reading-oriented extension components / API endpoints off his plate. I'll add the bullet points to the Etherpad for the recurring APIs/Services meeting instance tomorrow.
API action=mobileview : the apps are heavy users of this endpoint.
pageimages extension: Max noted that the algorithm needs improvement
for targeting the "best" image.
featuredfeeds extension (RSS/Atom)
TextExtracts is still an open question. Max said he can maintain it in
maintenance mode, if necessary. But if there's interest in Reading taking over future work on this, that would be even better. Max noted the persistence of the results is an area for improvement. Incidentally, some people have been communicating about this stuff today.
Thanks. -Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation