Bugs are Not Issues

This is the lighting talk I would have tried to fit into 5 minutes at UDS; but because I’ll be going to the Libre Graphics Meeting in Montreal instead; I thought it better to post the talk on my blog and get you all interested in the subject.

We’re after the release of Ubuntu 11.04. What to think about the many, many bugs we’ve fixed…

Bugs are breaks in the intended function of the software.

Bug reports are little packets of information for developers, they help point out where their software is broken.

Bug discussions are comments after the report which contain a dialogue between the developers trying to fix the issue and the people who can test it and provide more information.

So what do you do if you have a problem, but you’re not sure if it’s a bug? Perhaps the system was always intended to work like that?

What we need in these instance are Issue Reports, these are little packets of information which describe in user context what the issues the user is having. They can result into either support requests, blueprints or bug reports. they’re a proto-step to many divergent paths for getting stuff done.

How do we deal with issue reports in launchpad? At the moment we mash issue reports into bug reports with special tags. We also spray them into answers, askubuntu, irc, mailing-lists and brainstorm randomly based on what the reporter knows and what the reporter weighs up on the issue.

So how would I see a user centric addition fitting into our existing Launchpad ecosystem? Basically like this:

What are your thoughts? Do you like the ideas and do you think they would improve flow of relevant information?

Freely Fixing and Developer’s Time

I was reading over the ever wise Matt Zimmerman and his blog post about Listening to Users; in it he argues that user involvement is a nuanced subject and which approach the developer takes can be highly dependant on the timing, cycle and context of the developing project. Providing examples and some interesting comment.

I basically agree with these ideas, but I wanted to add something more to the economic thought.

I talk about user involvement here; I never mean users who are programmers, users who help support other users or users who turn into developers by their continued project involvement. For that subject see User to Developer evolution.

What developers want from users is fine communication on what the challenges and needs they are facing. They would like as much depth into the issues with as much detail on the specifics which cause issues. This communication is not actually in effort to help the user, but is instead a way to help the developer’s project. The user can see the bug or interaction as a way to get their immediate issue resolved, but the developer will be focused on collecting and filtering the relevant information and making tasks to push the project forwards.

Of course the user will still benefit in due course; but the user’s direct support needs are instead not met by bug reports, but by support type people who may or may not know the aims of the project. The goal for support people is to give the user instructions so that they can mitigate their issue and it isn’t about helping the developer. A wily support person will be able to turn a successful support request into a successful bug report which the developer can process and turn into a permanent solution; on the other hand a user or support person who is used to mitigation strategy, but not used to developer interaction will fail to tie the loose end of why the user needed support in the first place.

This can lead to the dreaded ‘toxic workaround’ which Tim Cole has given a talk about. This is a workaround which becomes so well documented and so ingrained in the culture of the users of a product that they fail to actually tell a developer to fix it. So the problem always remains causing issue for anyone new and causing users to go through extra steps to get usable systems. A good example of this is in Ubuntu support channels when people are asked to and expected to compile anything instead of the code being added to a PPA.

In order the listen to users, I think a developer must know the difference between supporting the user, and supporting upstream development; which may place conflicting demand on the developer’s time. The user for their part, if they get frustrated with reporting bugs that never get to be solved, can lash out at developers, ordering and demanding action should be taken and issues resolved.

Of course, if the user isn’t paying the developer to fix their issues, then the user has no right to ask any developer to work on their issue. The user’s only real power is that they can be of use to the developer’s aims in their project’s future refinement. This is because the developer is the one that holds the majority of the economic power. When a developer talks with a user, it’s clearly with an effort to solve the issues the user has brought up; but I think the developer is always thinking about what fixes will benefit the project the most and which users are the most useful to communicate with to achieve those goals.

What are your thoughts?

Ubuntu Insurance?

This idea popped up in a completely different conversation and I haven’t explored the full dynamics of the idea and how it would play out legally but:

What if Ubuntu users paid into an insurance fund. The fund’s aim would be to record the primary software and hardware used by the customer and to employ programmers and QA people to ensure that this software and hardware works in the next release and with critical updates?

Payout would essentially be getting people in to fix problems if they cropped up.

This would be in contrast to the idea of paying individually for bugs to be fixed. Such as having bounties or pay only bug trackers.

The goal of course would be to collectively take responsibility for maintaining the code we have that makes our computers do amazing things. Make sure that this is sustainable and reduce the requirement for guides and “toxic workarounds” for sets of problems that crop up in releases.

Would you pay into such a scheme? Do you know users who would? Is there enough money in our ecosystem to really pay people to do a good job on fixing problems or are we just not big enough yet?

What are your thoughts?