Goals

When it comes to bug work flow/triage we have two main goals (which we share with the Ubuntu project as a whole):

• Bring important bugs to the surface more reliably
• Churn through the open bugs more efficiently

Bug flow

The following chart describes the flow of a bug until it gets into the hands of a developer to work on. Orange represents a step anyone can perform, while yellow is reserved for those steps handled by Ubuntu One team managers. Details supporting this chart follow below.

Source: ubuntu_one_bug_workflow.dia

Status

The following statuses should be used by all those reviewing bugs:

• New: The bug is newly reported.

• Incomplete: The bug report is incomplete and needs more information before it can be triaged.

• Invalid: The report describes the software's normal behaviour, or is unsuitable for any other reason.

• Confirmed: A member of the community believes that this report describes a genuine bug in enough detail that a developer could start work on a fix.

The following statuses are set by the Ubuntu One team managers:

• Triaged: Ubuntu One team manager considers that the bug report contains all information a developer needs to start work on a fix.

• Won't Fix: this is acknowledged as a genuine bug but the project has no plans to fix it. This may be due to lack time and resources, we don't want to leave bugs in limbo if we aren't likely be able to schedule time to fix it.

The following statuses are to be set by the developer working on the bug:

• In Progress: A developer has taken responsibility to fix the bug and has begun work.

• Fix Committed: A developer has committed his/her fix to the project's codebase.

• Fix Released: A new version of the software, featuring the bug fix, has been released.

Assignment

Every valid bug should be assigned to one (and only one) of the following Ubuntu One teams:

• ubuntuone-client-engineering Handles the desktop and mobile work

• ubuntuone-foundations+ Handles items like syncdaemon, CouchDB synch, etc.

• ubuntuone-ops+ Handles infrastructure, testing, etc.

• ubuntuone-web Handles web ui.

• ubuntuone-design-ux Handles design and user experience tasks.

Please also tag these bugs with one (and only one) of these tags:

• desktop+

• foundations+

• ops+

• web+

• u1-ux

Don't worry too much if you aren't sure which team queue a bug should go into, if the team manager disagrees they will take care of moving it to the correct queue.

Tags

The following tags are used to help us find and sort bugs. Please use them where applicable.

• chicharra - Any syncdaemon or file sync server side bug

• u1-support - Any bug that was filed as a result of a support request

• u1-qa - Any bug that was filed as a result of QA tests failing

• u1-sru - Any bug that needs to be an SRU

• u1-windows - Any Windows related bug

Service Tags

In many cases it's helpful to tag the bug with the appropriate service. For example, tagging a web bug with "files" or "contacts" depending on which part of the web UI was impacted. Some common tags are:

• account

• contacts

• files

• music-store

• music-streaming

• notes

Also Affects

Every valid bug should be marked as affecting an appropriate Ubuntu One project if it is a package bug. For a list of projects see the Ubuntu One Launchpad home page. Note: Use ubuntuone-servers for any bugs related to the Ubuntu One web UI in addition to specific server side issues.

Importance

Importance is to be set by the Ubuntu One team manager:

• Critical - The bug dramatically impairs users. Users may lose their data.

• High - The bug prevents users from completing their tasks

• Medium - The bug is an inconvenience for many users

• Low - The bug is an inconvenience to users, but it does not prevent them from completing their tasks

• Wishlist - Desired functionality for future consideration.