Sorry for the slow reply, I was half-waiting to see if anybody else would jump in but I guess product managers don't follow dev-platform :)
I think we're mostly in sync on most of the nuts and bolts and the unresolved topics are generally pretty high-level concerns. On Thu, Jul 27, 2017 at 10:02 AM, Steve Fink <sf...@mozilla.com> wrote: > Unfortunately, there isn't anything written that explains actual criteria > in detail (its on our radar but somewhere behind a long list of engineering > tasks on the short-term priority list). > > > And I guess the parenthetical clause is what worries me. The people > churning through that workload should be churning through that workload, > and it's fine that they aren't spending time and mental space on the > theoretical concerns of future compatibility issues or addon developer > relations. But this is kind of a big deal for Mozilla strategically, so I > would expect someone else to be working on the strategic plan before we > reach the foot-shooting point. > > Hopefully, that someone would be in close contact with the engineers doing > the work, since they have the best context and familiarity with large parts > of the problem space, and hence their opinions deserve a lot of weight. As > long as the consultation doesn't get in the way of getting stuff done. > There's a ton of weight on you people's shoulders, and we don't want to add > more. > > One person can do both strategy and tactics (or implementation) just fine, > but it's usually not a good idea to do them at the same time. Different > mindset, different tradeoffs. > Again, documenting more formally specifically what it means for an > extension API to be safe, maintainable, performant, etc. is something we > know is needed. Hopefully when we come up for air after 57 we can work on > this (and complementary things like webextensions experiments). > > > Yeah, that's not really what I'm talking about. In a way, that's the hard > part. But it's unavoidable, and it's happening in practice, and I'm sure > there'll be a lag in formalization while things are taking shape. That's > probably a good thing, since it'll require experience to flesh these things > out. > > But that's about individual APIs. I want high-level answers to the > simultaneous questions "How are we going to expose sufficient functionality > to provide extension authors with what they need?" and "How are we going to > avoid shooting ourselves in the foot when we get further down the road?" > The sort of things you read in high-level strategy documents that set down > the goals, direction, and approach to known obstacles. (Not that I > necessarily want such a document; they're boring and make for dull reading, > and I'm always suspicious as to whether anyone's paying attention to them. > But I want the thinking behind it.) > I think the basic principles here are pretty simple and I tried to lay them out before. We're drawing a line and saying that we'll only expose things to WebExtensions that can be done in a way that is safe for users and maintainable for us (ie the people that work on gecko/firefox). Within those boundaries, we're willing to provide whatever extension authors need. Exactly how the terms "safe for users" and "maintainable for us" are defined is mostly an engineering decision (and occasionally a product or UX decision) and to be frank, we're still nailing down exactly how strict we should be (for what its worth I think we've personally been relatively conservative thus far). Anyway, I think the real strategy questions are about how much we will invest in building these APIs ourselves -- every engineer who is working on extension APIs is an engineer who is not working on performance or other new features. A related question is who exactly should be creating extension APIs. We have a dedicated team right now in the midst of a big blitz to bootstrap (no pun intended) the whole WebExtensions platform but in the longer term I think it makes a lot more sense for engineers who know individual areas of the code well to be the ones creating extension APIs that touch those areas. On the other hand, that's adding to everybody's already overfull workloads. This is a fine problem for engineering management to wrestle with while the rest of us keep busy writing code :) For further discussion about the longer term strategy, I would suggest following up with Kev Needham who oversees all of addons. Also, Mike Conca just started as the product manager for WebExtensions. But to be fair to him, he's now in his second full week here and if his experience is anything like mine was, he's still just trying not to get knocked down by the Mozilla-newcomer-firehose. -Andrew _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
