Alternative solutions for tracking workflow bugs are currently being discussed in various mailing lists (1, 2, 3). This page aims to list the current proposals with a short description and Pros/Cons to aid in the discussion. Please use a neutral POV in edits of this page.

Solution alternatives

1. Current procedure

• Workflow bugs are filed against the affected packages along with other Ubuntu bugs and are identifiable by the titles such as 'Please sync foo', the bug description and team subscriptions.
• Documentation is added to the bug triage pages explaining how to identify these bugs and that are best avoided

Pros

• No changes required to current development workflow

Cons

• These bugs are not very discoverable by users and triagers which will lead to future confusion
• Adds to the already extensive triage documentation, which raises the bar to entry
• Programmatic detection or exclusion of such bugs in scripts and generated bug lists is difficult

2. Assignment

• Worflow bugs should be assigned to teams (or individuals?) as assigned bugs are generally left alone by triagers

Pros

• Simple to implement
• Would yield tidy lists of assigned bugs for the related teams as a side-effect

Cons

• The use of assignment is itself not well standardised across the project, so this approach is not completely clear
• Inflates bug mail to members of the given team

3. Set to private

• Set workflow bugs to private to remove them from default searches of users and bugsquad
• Create a workflow-bugs team in LP containing at least bug-control and development teams so the bugs are visible to these groups

Pros

• Takes these bugs completely off the radar of users, bug filers and triagers who would normally not need to reference them

Cons

• Concerns that this creates a needless level of secrecy around what should be an open set of processes
• bugs become invisible to interested parties outside the Ubuntu project, including upstream developers
• These bugs disappear from search engine results and various statistics
• Not applicable for needs-packaging bugs which are often filed by users
• Adds another step to workflow processes, some of which are already a bit complex

4. Text notice

• Bugs in this category filed without this notice (might be common for needs-packaging bugs) could be usefully triaged by the bugsquad by adding the notice and subscribing the right team
• Example:

WORKFLOW BUG: This bug is used for a development process and 
does normally not require further triage or user comments. 
Please see https://wiki.ubuntu.com/WorkflowBugs for more 
information about workflow bugs.

Pros

• Simple to implement on both new and existing bug reports.
• Informative and self explanatory

Cons

• Requires an additional copy-and-paste operation for each new bug of this type
• Looks untidy and dumbed down

5. Tags

• A single 'workflow' tag or separate tags for the different tasks

Pros

• Simple to implement

• Once tag subscriptions were implemented (bug 151129), the various teams wouldn't need to exist any more. For example, someone who dealt with sync requests could either subscribe to the "sync-request" tag, or occasionally look through the reports with that tag, depending on their level of involvement.

Cons

• Tags are a bit cumbersome to use (bug 83736, bug 98585, bug 127138, bug 184737).

• Not as self-explanatory as a text block with a link

Comments

To address the tag cumbersome issue, I made a buttontags greasemonkey script that makes tags a lot more convenient to use. -- bryce

On the mailing list there was discussion on hiding workflow bugs (which would require changes in Launchpad) but, wouldn't it be better (and possibly easier to implement) to add a workflow bug-type to Launchpad (somewhat like the patch tag). The difference to option #5 would be that a) it should be easier to set than a tag (although internally it could still be a tag, which could just be filtered out from the list, or even just let it be a new "importance") and it would display a text telling that the current bug is a workflow bug, when it's set (like the duplicates info bar). -- RainCT

"Workflow bug" is a weird term -- they're not workflow-related, and they're not bugs. They're requests to do a particular thing. One long-term approach would be to generalize the Launchpad Bugs tracker into an issue tracker that classified issues into (a) defects, (b) feature requests/blueprints, and (c) other to-dos such as the ones discussed here. They'd all have the same statuses and importances, but it would be more obvious that to-dos should be left alone except by their reporters/assignees. -- MatthewPaulThomas