L20n/Tracking

This page explains how we're tracking bugs and feature requests for L20n.

Bugzilla

File bugs in the L20n product in Bugzilla (see the Contribute docs if you want to contribute code).

Useful links:

• Dashboard

• Untriaged bugs (a triaged bug is a bug with a non-empty priority or target milestone set to Next)
• blocking-parkcity+
• blocking-parkcity? nominations
• APIchange

• Target Milestone: 1.0
• Target Milestone: Next
• Open bugs tracking 1.0 work by assignee by priority

• JS Library and Bindings targeting 1.0 + untriaged
• Evangelism and Geenral targeting 1.0 + untriaged

• All open bugs
• Browse all components

park-city

the bug blocks a design decision for 1.0 API, but it doesn't have to block 1.0 itself

APIchange

the bug potentially has an impact on the API

1.0 beta

a pre-final release with a stable API

Triage

Time

TBD

Dial-in

+1 650 903 0800 x92 Conf 359#
+1 800 707 2533 (pin 369) Conf 359# (toll free, Skype)

Bug list

http://bitly.com/l20n-triage

Release planning

Planning what goes into a particular release should be done via the Target Milestone flag. All bugs that we want to fix in the 1.0 release should have Target Milestone set to "1.0". Setting Target Milestone to "Next" means that we recognize that we want to fix the issue in the next release. No Target Milestone means that the bug might get fixed on one of the future releases.

Dependencies

Bigger chunks of functionality can have tracking bugs, blocked by smaller items of work. Neither should be version-specific.

For instance, if we were to implement a "Better debugging info" feature, we would perhaps file a tracking bug. Some of its dependencies would have Target Milestone set to 1.0. Others would not.

Priorities

P1

All other work stops, all team focuses on it, our product is broken.

P2

This is important enough that we cannot *not have* someone assigned to it and work on it. It might be a new feature or a bug that affects many users. Also, a bug that blocks someone else's work.

P3

We recognize this needs to be done, but we won't work on it until all P2s are assigned: "I'm not sure exactly what I should be working on right now, so I'll assign one of P3s to myself and start hacking on it."

P4

This would be nice to have, but is not crucial and doesn't block us. Usually, a good "first bug" that we can afford leaving open for a newcomer to pick up.

P5

Not used.

Severity

Severity is set by the bug reporter to let us know how serious the issue is for them. Imagine a bug in L20n that affects only Polish. It could be marked as 'critical' but still be a P3 and only fixed in a future release.

Considerations for the future

For now, we don't use any custom tracking flags. We'll revisit this after 1.0.