launchpad developmentThere are 3 different types of requests Launchpad Translations team commonly deals with: bugs (problems) in software, new feature requests and administrative requests (for projects other than Ubuntu; for Ubuntu, you should go to UTC team).
These are respectively handled by bugs, blueprints and answers applications in Launchpad. Use them appropriately, and you'll greatly aid us in better responding to your request.
To track development, we also make use of milestones in Launchpad, and a priority wiki page.
Bugs
For any problems with Launchpad Translations (i.e. Rosetta), one should file bugs. This explains statuses we use when tracking bug reports.
If you are unsure if what you are reporting is a bug, please ask a question instead (which can easily be converted to a bug later on).
Status
Bug status |
Used for |
New |
Incoming queue of untriaged bugs. |
Incomplete |
Bugs with no sufficient information to help us nail it down or figure out what it's about. |
Triaged |
We will work on this, but unless assigned to a milestone, it's probably poorly specified. |
In progress |
Active effort is put into solving the bug or it's already in code review. |
Fix Committed |
Bug fix has landed, and a comment is added that includes a revision ID and branch it has landed to. |
Fix Released |
Once a bug fix rolls out to production servers (i.e. launchpad.net). |
Priorities
TBD.
Blueprints
While developing Launchpad Translations, we make use of blueprints application in Launchpad to track new feature development (though, some times, we'll use bugs for that as well). This is a basic mapping of statuses we use to indicate progress on implementing a blueprint, and their mapping to more officially recognized bug statuses above.
Blueprints develop through two stages. One is definition, and another is implementation.
Definition status
In general, we do not track definition in too much detail, so we only want to use two values for "Definition Status": New and Approved. Obsolete and Superseded are allowed where appropriate, but other statuses should not be used.
Implementation status
Implementation status should be Not started on any blueprint that has a definition status of "New". For any other statuses, definition status needs to be "Approved", with "basic direction approved" ticked and priority set on the priority page of a blueprint.
We use only Unknown (tor untriaged blueprints), Not started (for triaged blueprints), Started, Needs Code Review, Deployment and Implemented values for implementation status.
We do not use: Deferred, Needs Infrastructure, Slow progress, Good progress
Mapping bug status to blueprint status
Bug status |
Definition status |
Implementation status |
Comment |
New |
New |
Unknown |
Incoming queue of blueprints corresponds to untriaged bugs. |
Incomplete |
New |
Blocked |
Something is blocking definition/implementation of the feature (whiteboard should explain what it is). |
Triaged |
Approved |
Not started |
We will work on this, but unless assigned to a milestone, it's probably poorly specified. |
In progress |
Approved |
Started |
Work is in progress on the blueprint. |
|
Approved |
Needs Code Review |
Code has been proposed for merging, i.e. a developer believes it's fully implemented and is asking for peer review before they can land it. |
Fix Committed |
Approved |
Deployment |
Change is in the process of being deployed: it has landed, and whiteboard includes a revision ID and branch it has landed to. |
Fix Released |
Approved |
Implemented |
Once change rolls out to production servers (i.e. launchpad.net). |
