Architectural work and big platform features we deferred to post-v1. Mostly gecko items, but tracking from b2g product since these are items important to b2g.

I'm going to use this for bugs that are sort of "general platform improvements", what we can pick and choose on train-like schedules for products. We already track product requirements, so I'm going to leave those off here, even where they would fit the theme.

<Jesse> of course, "next" will become incorrect at some point :/ There's always a v.next, which is why I chose that name ;).

There will be more to come, but I'm going to start tagging these bugs (with explanations where possible) as [tech-bug]: user-visible defect that we need to fix asap. Highest priority. [tech-p1]: needed for competitive parity, or major use case for content [tech-p2]: important use case for content, or major technical issue to fix [tech-p3]: nice-to-have use case, or important technical issue

Facebook developer ringmark [1] the following way: They looked at popular native mobile apps in non-web platforms and sat down to see how they could reproduce these apps with web technologies on mobile. They gave priorities based on frequency and developed the rings tests. I'm adding the ringmark bug as dependency as I feel it contains a lot of interesting information for B2G to follow in terms of mobile app developer expectations. [1] http://rng.io/

(In reply to Chris Jones [:cjones] [:warhammer] from comment #3) > There will be more to come, but I'm going to start tagging these bugs (with > explanations where possible) as > > [tech-bug]: user-visible defect that we need to fix asap. Highest priority. Should clarify that these *technical* priorities, not product priorities. Except for tech-bug's which we need to fix yesterday, for a product I would probably take some tech-p2 bugs over tech-p1. F.e. bug 842217 over bug 711613.

I'm the defacto maintainer of Ringmark/rng.io and also working fulltime on Gaia (@ Bocoup)

Just a random thought (since this is a big bug tree with lots of management involved) - it might be a bit more scalable to make use of a project flag here. Something like: v1 technical next <-- flag name v1 technical next = ? <-- nomination from random person v1 technical next = bug, P1, P2, P3 <-- exact info you just stated Then build simple dashboards/queries that allow you to look at this from each perspective - noms, bugs, P1, P2, etc. You could do something similar with whiteboards I guess, but this seems general enough to b2g that a project flag might be worthwhile to make use of.

tracking flags are a different use case that we will need for these bugs eventually too. sadly there's not a more general mechanism serving both in bz. phone

Firefox OS is not being worked on