> In general I'm in favor of more ad-hoc project-specific teams rather than completely siloing every service to the Services group, or every mobile UI to the Mobile group.
I strongly agree. Based on experience on both sides of this spectrum, I recommend (when feasible) favoring feature teams over functional teams. On Wed, Feb 4, 2015 at 3:00 PM, Brion Vibber <bvib...@wikimedia.org> wrote: > I think the way we'd want to go is roughly to have a *partnership between* > the Services and Mobile teams produce and maintain the service. > > (Note that the state of the art is that Mobile Apps are using Mobile Web's > MobileFrontend extension as an intermediate API to aggregate & format page > data -- which basically means Max has done the server-side API work for > Mobile Apps so far.) > > I'd expect to see Max and/or someone else from the Mobile team > collaborating with the Services team to create what y'all need: > 1) something that does what Mobile Apps needs it to... > 2) and can be maintained like Services needs it to. > > In general I'm in favor of more ad-hoc project-specific teams rather than > completely siloing every service to the Services group, or every mobile UI > to the Mobile group. > > -- brion > > On Wed, Feb 4, 2015 at 2:29 PM, Corey Floyd <cfl...@wikimedia.org> wrote: > > > On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke <gwi...@wikimedia.org> > > wrote: > > > > > Regarding general-purpose APIs vs. mobile: I think mobile is in some > > ways a > > > special case as their content transformation needs are closely coupled > > with > > > the way the apps are presenting the content. Additionally, at least > until > > > SPDY is deployed there is a strong performance incentive to bundle > > > information in a single response tailored to the app's needs. One > > strategy > > > employed by Netflix is to introduce a second API layer > > > < > > > > > > http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html > > > > > > > on > > > top of the general content API to handle device-specific needs. I think > > > this is a sound strategy, as it contains the volatility in a separate > > layer > > > while ensuring that everything is ultimately consuming the > > general-purpose > > > API. If the need for app-specific massaging disappears over time, we > can > > > simply shut down the custom service / API end point without affecting > the > > > general API. > > > > > > > > > I can definitely understand that motivation for providing mobile specific > > service layer - so if the services team wants to implement the API in > this > > way and support that architecture, I am totally on board. > > > > My remaining hesitation here is that from the reading of this proposal, > the > > mobile team is the owner of implementing this service, not the services > > team (Maybe I am misreading?). > > > > This leads me to ask questions like: > > Why is the mobile apps team investigating which is the best server side > > technology? That seems outside of our domain knowledge. > > Who will be responsible for maintaining this code? > > Who will be testing it to make sure that is performant? > > > > I'm new, so maybe these answers are obvious to others, but to me they > seem > > fuzzy when responsibilities are divided between two teams. > > > > I would propose that this be a project that the Services Team owns. And > > that the Mobile Apps Team defines specs on what they need the new service > > to provide. > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
