Ubuntu User: I have a problem…

At UDS-O I led a session on improving the community involvement with Bugs. The original intent had been to ensure that Ubuntu users understood the bug life cycle, but as the discussion progressed it became clear that the wrong assumption had been made. We had forgotten that there would be group of users who would not have any interest in putting in a bug report or following it through the life cycle. The wrong starting point was also being discussed at the beginning. Users do not have ‘bugs’; they have problems. A problem may end up being a bug, but it could be many other things as well.

In the end the goal was still the same. Increase Ubuntu users understanding of the support ecosystem to ensure that they had valid expectations and improve the quality of the bug reports being put in to launchpad.

The first step in the process was to create a high-level diagram of the process. For some this diagram will be too non-technical, but the aim was specifically to reduce technical details. Other documents will be created that can provide a deeper dive in to bugs and QA. I would like to gather some feedback on the diagram as it stand now. Thanks for Brian Murray for helping edit the diagram with me.


ubuntu-problem diagram

Creative Commons License
ubuntu-problem by charles profitt and brian murray is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

This entry was posted in Linux, Ubuntu. Bookmark the permalink.

19 Responses to Ubuntu User: I have a problem…

  1. Xavier Verne says:

    Hey, nice work.
    I can easily imagine a ubuntu-process.com with main diagrams like this (translation, community involvment, decision making, etc…)

    which tool did you used to draw this diagram ?

  2. Bruno Girin says:

    The diagram immediately demonstrates the issue you talk about in your blog post: if the problem is not resolved immediately via IRC, the forums, etc, the user has to make the mental leap that in order to resolve a *problem* with *Ubuntu*, they have to file a *bug report* in *Launchpad*. This is a simple step for us techies to make but is a giant leap for a lot of users: what is a bug report? Why do I need to file it in Launchpad when my problem is with Ubuntu? Add to this that the Launchpad interface is rather dry for a first time user and has nothing that visually recalls Ubuntu and I wouldn’t be surprised if a lot of people just don’t bother.

    Once they’ve passed that hurdle, they are confronted to the bug resolution process. Once again, it’s a process that makes sense for anybody in the IT industry but not for anybody else. A question that I’ve seen asked a couple of time is: “why do I have to give Launchpad my email address and everything, can’t you just fix my problem?” After that, there is the frustration related to having to answer questions from bug triagers who are trying to reproduce the problem. Once again, we understand why that is, most non-techie users don’t.

    After that, there is the final verdict: confirmed, won’t fix, etc and the priority assigned to it. Very often, if users have gone past all the previous hurdles, it means that the issue is critical for them, even if it is not critical for Ubuntu. So some of them do feel let down when their problem is considered to not be that important after all.

    And finally, the resolution. If the bug is not critical, they have to wait a full release cycle at least (possibly more if the defect is upstream and upstream don’t pay attention).

    So what can we do to fix that? Maybe the front-end for Apport should be extended from a simple UI that initiates the launchpad journey into a full Ubuntu branded launchpad front-end that helps the user along the way and tries to be smart: for example, such a front-end could do things like:
    – if the user is registered with Ubuntu One, don’t ask them to register again; otherwise explain that the registration is essential for Ubuntu to come back to them with questions and progress reports;
    – guide the user in explaining the problem in their own words (don’t use the word bug!);
    – tell them what will happen next;

    Once the bug is fixed, rather than force the user to wait for the next release, what about using bug fix PPAs and integrating the whole thing with the software centre so that users can install a fix for their problems while not having to release the fix as part of a SRU?

    Does the above make sense or am I barking at the wrong tree?

  3. The solved->yes branch includes local workarounds for the encountered problem, yes? This is the path of the known workaround. Actually there should be a second path for yet unknown workarounds which are developed while triaging/bug fixing and can be applied locally without a development fix or SRU.

  4. scaine says:

    @ Bruno : “So some of them do feel let down when their problem is considered to not be that important after all.”

    I think that’s HUGELY understating the issue. Duplicates and wishlists are one thing, but if I can’t get two-fingered scrolling (say) working in Ubuntu, and it works in Windows, the moment you mark the bug as “won’t fix” because it’s a kernel problem… that’s the moment you’ve lost an experimental Ubuntu user back to Windows.

    The diagram is very useful, Charles, as a visualisation of a process I’ve only dimly understood until now. However, it doesn’t take into consideration the emotional impact any of this has on a “standard user” which is what you say you’re aiming it at. “Wait for next release” for example, isn’t an option for someone with trackpad or video issues that are driver related and when those same issues don’t exist in Windows. You might not want to be so negative in your review of this process but that option is more likely “go back to windows”.

    • Charles Profitt says:

      The diagram is just step 1 to helping new users. The other part of what needs to be done is some text that reminds users that the Ubuntu Dev Cycle of six months makes the ‘next release’ similar in ‘wait’ to a Windows Service Pack. I also want to gather some statistics to illustrate the response time of Microsoft and Apple to ‘home users’ in regards to ‘bugs’ they have in the OS. From a non-scientific approach my gut tells me you will wait much longer to get a response from Microsoft and with Apple I have been told ‘buy the next version’ on too many occasions.

    • mase says:

      “I think that’s HUGELY understating the issue. Duplicates and wishlists are one thing, but if I can’t get two-fingered scrolling (say) working in Ubuntu, and it works in Windows, the moment you mark the bug as “won’t fix” because it’s a kernel problem… that’s the moment you’ve lost an experimental Ubuntu user back to Windows.”

      I don’t see how you can fix that problem though…. if someone needs / wants two fingered scrolling but the code doesn’t exist or requires someone who understands how to fix the code to look at it then what can you actually do at that point ?

      As far as I am aware, Canonical is the only company paying developers to work on Ubuntu and they have zero incentive to get their paid developers to fix an issue which is unlikely to result in a significant ( any ) increase in revenue.

      The same issue occurs for PPA’s since manual work has to be done although this work can generally be done by a member of the community. However you still have to convince someone that they should bother doing this work for you.


      • scaine says:

        Very true. I don’t have a magic solution. The whining and threats of “I’ll go back to Windows” are a recurring theme throughout my 6 years of Ubuntu – forums originally and latterly on AskUbuntu (where it’s less of an issue).

        Some kind of education wouldn’t go amiss, perhaps? All too often a bug report will “demand” a fix, which then triggers condescension from devs who may ultimately be unwilling or unable to help in the first place!

      • muppetjones says:

        I think the underlying issue is that the users who do that probably aren’t going to stay around anyway. Before I made the switch to Linux, I had toyed around with it for years, but because I didn’t have a solid reason to use Linux at the time (e.g., I needed Word, I was required to use a Windows only IDE), I just stayed with Windows.

        Not to say that some won’t stay, but the point is that while most experimenters may want to use Linux, many won’t keep it until they need to use Linux. The same is true for specific Linux distros. There are distros that I really want to use, but I just don’t have the time to spend getting everything working on every computer. So I use Ubuntu as it has (had, ugh Unity ((I haven’t tried Gnome 3, though… I might not like it either)) ) everything I need with minimal setup / error resolution required.

        Linux may pick up more users, but because it is what it is, it will never be able to go mainstream without complete support from a company in the same way that Apple and Microsoft support their OS. The irony is that if that happens, Linux will most likely cease to be Linux.

        That said, I like the flow chart. Great work!

  5. Pingback: Ubuntu User: I have a problem… « Free Trader Beowulf | Linux Blog

  6. Lipe Forman says:

    I like the diagram it is good for the “bug” solving part of the problem. I think we need to look at this from the users side perspective and expectancy. First we have several types of users, Techies, Experienced, new comers, children, older, etc.. Each of those user types have a different perspective of what is a problem and what they want to achieve on a computer.
    Some users will not bother to fill any kind of problem report, other will try and stop when it begins to be too much trouble to answer it. normally only the techy or the guy who wants to be involved with the community will fill the report till the end.

    I think we should make a process where reporting a problem should be as simple as possible and that gets as much information as possible automatically without, logins, registrations and etc. The process should also ask if the user wants to follow the resolution cycle or not. Sometime i just want yo report something that bothers me and would be nice to be fixed, but i have a work around for it.

    Then i suggest that on the revsion of the report that a classification could be done looking to see if the information gathered was enough or not, if the problem could be reproduced, and if the user wants to follow it, if the user does not want to follow it, put appart and see if there is similar errors reported, if the amount of reports on similar issues are in a good volume then we know that an investigation needs to be putt in place.

    hope i helped in some degree. if you want we could discuss more deeply.

    • mase says:

      “I think we should make a process where reporting a problem should be as simple as possible and that gets as much information as possible automatically without, logins, registrations and etc. ”

      Lowering the barrier to submitting a report is good however for a bug report to actually have a chance of being useful you need a certain amount of information and it’s unlikely that most users will complete a satisfactory bug report the first time around, so it’s more than likely that you will need to contact that person and ask for more information.

      As a person who actually tries to fix some of these bugs, if a bug report doesn’t have enough information i will generally move on to the next bug until i find one which has enough information that i can go “I think i can easily replicate that and it’s a project that isn’t too hard for me to set up a development environment for”.

  7. trampster says:

    Wait for the next release is an unacceptable position. Bug which may exist in upstream for on a week can end up stuck in ubuntu for 6 months. In what way does this improve stability. It doesn’t improve stability instead it locks in instability for 6 months.

    • Charles Profitt says:

      After learning more about the process I think it is very acceptable. The alternative is that one fix might cause instability in other applications. If a bug is not deemed critical the process, as defined, is to put the fix through the full process of alpha, beta and release candidate to ensure it does not cause a regression in other areas. Think about how many times a Microsoft or Apple patch has caused a regression and then another ‘fix’ is released. As a Windows Systems Administrator I have seen far too many of those to demand a fix. Consider, as well, that the typical release cycle from Microsoft spans years. In the time it took Microsoft to release SP1 for Server 2008R2 Ubuntu would produce four releases.

      • scaine says:

        You think it’s acceptable, but I think trampster’s point is that the user won’t? I keep harping on about it, but if you get someone trying Ubuntu for the first time and the bug fix is “wait for next release”, then you’ve just lost a user.

        • Charles Profitt says:

          I agree with you. Windows and OS X users do not get instant gratification either; why should they expect it with Linux?

  8. Ian Weisser says:

    Problems can also include Simple Questions, Support Requests, Complaints, Wishlist Items, and General Improvement Ideas.

    Do you wish to diagram other complex problem flows? Like how some general complaints are supposed to be addressed to the appropriate Team, and possibly raised at UDS? Or the process that gets Wishlist Items (sometimes) into the Bug Tracker and (sometimes) into Ubuntu…or Debian instead?

    Brainstorm is another Problem venue.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s