DrinkingFromTheFirehose

Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2006-06-09 03:22:39 →
Size: 2775
Editor: c-24-17-241-65
Comment:
← Revision 3 as of 2006-06-09 17:45:39 → ⇥
Size: 3254
Editor: chiark
Comment: support vs bugs
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
 * Many bug reports are of low quality; sometimes even aggressive interaction with the submitter fails to improve matters. This is discouraging and wasteful of both submitters' and developers' time. We should try to direct most users to support setups rather than bug systems and maybe we should consider making bug reporting tools less visible and less easy-to-use, as well as improving the interface to make it easier to submit good informative and detailed reports. -iwj

Summary

In this specification process, we will try to figure out processes how to get on top of the exponentially exploding number of bugs.

Rationale

Bug numbers are climbing. Community members are helping us out and reading every single bug just isn't feasible any more. We need to figure out new approaches to work with our bugs effectively.

Use cases

Sébastien reads all Desktop bugs to try to stay on top of things. This takes him most of his day.

Mike wants to get involved in BugSquashing, but isn't sure where to start or what to do to help out effectively.

Brad wants to optimize views on bugs to make the developer's life easier.

Simon wants to set up a tool to send notifications for certain bugs to certain package maintainers.

Scope

Design

Implementation

We should have at least four sessions together to

  • identify problems,
  • brainstorm about possible solutions,
  • figure out robust processes to make our lives easier.

You've got millions of users, so this is no surprise. No simple way around this problem other than getting more resources. Solutions should be goal driven:

  • All 6000 unconfirmed bugs get confirmed
  • All bugs filed in one or more upstream codebases. Upstreams will fix most of your bugs, but they need to know about them. This should be high priority.
  • Many bugs have fixes in upstream code. Being able to query this state would be good.

Recruit help from the community:

  • How many Ubuntu users know C/C++ and could submit patches to the upstreams? Maybe you could create a (virtual?) conference to recruit people with such skills. I think this is hard because understanding even a 20kloc component takes months, but knowing how many Ubuntu users have contributed patches to OSS code before would give you a good sense of this number.
  • Could an Ubuntu community team of be created to take ownership of various areas and be responsible for cleaning up the buglist and making sure bugs quickly get filed upstream? If Ubuntu devs are doing this today, could this be done by the community, freeing up Ubuntu devs for harder stuff?

All distros have lots of bugs. However, Linux on the desktop is gaining momentum, and the upstreams are working hard on fixing bugs (if not, yell at 'em) and will prioritize Ubuntu bugs.

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

  • Many bug reports are of low quality; sometimes even aggressive interaction with the submitter fails to improve matters. This is discouraging and wasteful of both submitters' and developers' time. We should try to direct most users to support setups rather than bug systems and maybe we should consider making bug reporting tools less visible and less easy-to-use, as well as improving the interface to make it easier to submit good informative and detailed reports. -iwj

CategorySpec

DrinkingFromTheFirehose (last edited 2008-08-06 16:19:26 by localhost)