Improving Bug States and Workflows

Notes:
- A survey was created and an e-mail was sent to ubuntu-devel to find out how people feel about using Launchpad. (44 responses - ~1/4 of Ubuntu Developers) (Note: There are > 2500 subscribers to the ubuntu-devel mailing list). Some results are:
  - People feel they do more manual work than should.
  - Not possible to look at bugs, but better tools could be make it possible to look at them
  - Opinion status is not used
    - Opinion status going away is an open task on Launchpad and is something they want to do
  - People are using tags in way that could be considered as bug state for workflows.
    - Kernel team would like custom per project status.

Ideas:
- In order to work with upstreams better need to have 1:1 mappings with bugzilla states.
  - Definition of the statuses - https://help.launchpad.net/Bugs/Statuses/
  - Definition of how LP translates external statuses to LP statuses: https://help.launchpad.net/Bugs/Statuses/External - (can be found in lp source code: launchpad/lib/lp/bugs/externalbugtracker/bugzilla.py
- "Incomplete" is sometimes used for fixes that need testing, and then expires when it shouldn't.
  - Expiration can be blocked in a variety of ways, for example by having an assignee
- Consider renaming "Triaged" to "Ready" (or "Ready to Fix")
- Possible removal of states (Opinion, first of them)
- Gentle social pressure towards standardization, by making definitions visibile in the Launchpad web interface.
  - What do bug statuses mean to each Ubuntu development team? For example, QA subloop - fix committed, activate QA states, verification, set to fixed released. It varies.
- Diagram the ideal workflow for each team and how they map it to current representations in Launchpad. Look for the mismatches between the two.
  - Proposal that each of the teams to check against.
  - Interesting cases to consider:
    - SRU flow.
    - Kernel config.

Work Items:
[ursinha] Find and publish notes of the DAs discussion on which parts of the bug workflow are common to all engineering teams: DONE
[ursinha] Create a convention for documenting state diagram for teams workflow currently (similar to this: https://dev.launchpad.net/MergeWorkflow and https://dev.launchpad.net/QAProcessContinuousRollouts) and broadcast to workflow documenters: DONE
[ursinha] document server team workflow: DONE
[ursinha] Ask people who work with ubuntu-software-center how they use it as well as they seem to have a yet different bug workflow (requested by mpt): POSTPONED
[brian-murray] document foundations team workflow: DONE
[ursinha] work with pvillavi to document desktop team workflow: DONE
[jsalisbury] document kernel team workflow: DONE
[bryce] document X-Team workflow: DONE
[cgregan] document CE team workflow: DONE
[ursinha] document SRU bug workflow: DONE
[kate.stewart] Organize followup meeting half-way through the cycle to review the differences between teams.: DONE
[ursinha] First draft unified workflow. This workflow should look at bug assignment as a part of it as people seem to use assignment differently: DONE
[kate.stewart] Discuss in the next Thunderdome/Rally with Launchpad about the common workflow we have so far and figure out improvements: POSTPONED
[flacoste] Will discuss how to implement the user needs from the proposed common workflow.: POSTPONED