How we could use Bugzilla for User Support

49 Replies to “How we could use Bugzilla for User Support”

1. IMHO, advantages of your approach are more important of the disadvantages.

   However, the second level support could be a particular section of the forum, in which there are the bug reports that must be confirmed by many users. When lots of users confirm the bug report, then the moderators of the forum report it to the developers.

   1. many users confirming a “bug” doesn’t make it a “bug”. There are issues which just are no bugs, but which might be wishes for feature changes. For that we already have the brainstorm section.

      1. Currently however the Brainstorm section is a bit behind because it’s hard to integrate it with Bugzilla. Help is welcome in this area.

         1. Personally I doubt there is any added benefit of moving the brainstorm ideas to the bugtracker. For me as a developer it is much more valuable to be able to browse the ideas on the brainstorm section than to search through the wish list which contains a decade of random ideas I never look at.

            1. The idea would be to submit ideas to Bugzilla *after* the discussion in Brainstorm. That was the original purpose back in the days.

               1. yes I know, but for that to work the wishlist items would have to be well managed. In case of KWin there are many things there which just don’t make sense or would take weeks to implement or are a usecase just for a handful of users. So the moderated ideas from brainstorm just disappear.

2. A less extreme idea would be (as suggested on #kde-www and from my post in k-c-d) to make forums more visible in bugzilla (offer a link to the forums in the bug report form) and eventually (in frameworks) put an additional entry in the Help menu to go to the forums.

   1. both are good ideas and I would like to have the help menu entry even before frameworks

      1. I say frameworks because if you recall a similar idea for Join the Game went nowhere.

3. While I totally agree that support questions do not belong in a bug tracker I don’t think closing b.k.o is a good idea, on the contrary. I suggest a link to the forum on our bugzilla implementation in the style “..if you are not 100% sure that you are going to report a real bug, please ask in http://forum.kde.org first”. But closing the bug tracker globally is a very bad thing, and ultimately I think it will generate more work.

   Again, in an ideal world every project would have its own dedicated bug triager so bugs are only confirmed once the triagers have done their work. Once a project has a well triaged database it is quite easy to handle. It is also possible to send reminders for the most important bugs (regressions, release blockers) to the developers automatically, a feature we use in Amarok systematically.

   In Amarok when support questions come in I close those as invalid and point people to the forum systematically, but there are not that many to this date. On the contrary, I have to prevent people to actually report bugs by pasting backtraces to the forum which causes the complete thread to become barely readable.

   1. For KWin we have to do the complete user support to figure out whether the user is having a user support issue or found a bug. So for us it would be valuable to have the tracker closed. Especially as we do not live in a perfect world where there are triagers. In the KWin case the triager would have to do user support, so why do it in the bug tracker where it is unsuited?

      1. Maybe it would be a good idea (for example for KWin) to have only “read” access to bugzilla and have a link to the forum somewhere inside the bug report for the “normal” user discussion.

         1. that’s the idea I propose here 🙂

      2. But where do your second level support come from? I’d go with Myriam’s suggestion but in addition have a _separate_ ticketing system (customised such that resolutions are “answered” or “unanswered” and a bit more friendly to non-devs, not “fixed” or “invalid”) for second level support which anyone can access too — then you tell users who aren’t sure what to do to use the forums and those who think they’ve found a bug to use the second-level support system and add some nice documentation somewhere (or in many places) explaining this. Obviously whatever tools the second level support people are going to use are going to have to be open if you’re going to attract people to do that job too.

         Forums have a major downside: searching for information can be a pain because people never stick to the topic for long (and on top of that, threads are often badly named, etc.), so having the second level visible would make it easier for users to find their own answers.

4. Together with that older post http://blog.martin-graesslin.com/blog/2011/09/developer-and-user-interaction/ i get the feeling that you get more and more the attitiude of “Hey user, leave me alone with your problems, i am a developer.”

   1. Maybe a comparison would be helpful here … do you know the saying that developers are bad designers and designers are bad programmers?

      It can be quite similar with communication between users and developers. It can happen that the way some developers talk to the users can be very bad for the public image of a project. This could happen because the developer might be a little asocial, doesn’t express very well in English (it is a foreign language), has some personal problems or is just not in the mood to answer to the same question for the hundredth time. Also the time that a developer spends on the “community management” (finding duplicate bug reports, arguing with users because of some detailed technical problems that the user might not understand etc.) could be better spent on solving actual bugs or creating new needed features.

      It is good to have a buffer and/or a filter between users and developers … it can help both sides. But this means that you then need people to be in direct contact with users and try to filter out the real bugs. It could also help solve user “problems” faster by using a format that is closer to the users (users could get confused on how to actually use bugzilla).

   2. could you imagine that I actually want to help users, by fixing bugs and by answering in a support forum? Maybe both is not possible if users post their support requests as bugs.

   3. You might, but you would be wrong. Martin is for example quite active in the german ubuntuusers forums, most KWin-related problems are solved thanks to his knowledge.

      Being a software developer myself I can fully understand Martin. Good Bug reports actually help to make the software better, bad reports from users where something just doesn’t work don’t belong in a “bug”-tracker.

      At ubuntuusers, we get support requests. Some users even say they think it might be a bug. Some of us then try to confirm and if we do we either tell the user to report, or, if it’s a more complex thing, might even do it ourselves. So I think that for actual end-user software this approach is a very good thing.

5. I personally hate forums… All the time when I need to ask a question and at the end is a forum I just leave it unaswered or try to search again all the web. The forum is not welcoming for such things, and I hate(and I think that I am not the only one) to register to evey single forum when you just have to put a simple question or to answer a simple question. I like more how stackoverflow.com or askubuntu.com (which are actually the same thing) is implemented to do this kind of things. Press Ask a question and you are ready to go, easy to read interface and all the features that actually are needed for such a thing are there, the user can accept an answer and it’s visible to everyone that the question is market green, as solved, you don’t need to search through all the threads and all the posts….

   1. Forgot to say: + as the experience tells people are very active on stackoverflow.com / askubuntu.com sites because people fight for getting rating/points for contribution, questions are answered pretty fast and then improved. And I think that a lot of people will be able to use stackexchange because the Log in system can use: Stackexchange accounts, Google accounts, Yahoo, OpenID, Facebook and whatever else you add in there(for example askubuntu.com added Launchpad/Ubuntu One Login)

      1. I think we need a bugtracker that’s kind of based on the SO model, and perhaps only 10K users could actually flag things for developer attention

         1. On Stackexchange sites(Stackoverflow, Askubuntu…) there is a Privilege for points system. The people that create a custom Stackexchange site set the points needed for some specific privileges. So, if someone contributes a lot and people vote up his decisions and responses than he gets a lot of points and privileges… It kind of does the thing you are talking about. It’s something like the Open Source structure…

   2. Did you try forum.kde.org at least? It seems you didn’t…

   3. forums are just one possible way to get support. I today had a look at stackoverflow and am considering to get in discussion with the forum people whether we want a custom stackoverflow implemented.

      1. A little correction, Stackoverflow and Askubuntu are based on Stackexchange: http://stackexchange.com/ . “a custom *stackexchange”. I hope you don’t get it as being rude.

   4. But this could be compatible with the normal forum, couldn’t it? I mean, you could write a mod that puts the question / answers more to the foreground, and lets you mark individual posts as answers and rate them. An alternative section like the brainstorm forum could be created that shows a list of questions instead of the normal tree structure, enriched with tags and ratings, while the individual threads still appear in the normal forum structure.

   5. Stackoverflow and the like indeed are great! I’ve found lots of answers to my questions there and I didn’t have to dig through a lot of contributions/pages to find them.

6. sounds to me like KDE needs a corporation in front of it. Also, perhaps a better designed bugtracker that facilitates this kind of support.

   1. and who on earth will you find willing to do L2

      1. That is exactly what I was also thinking while reading this: if you don’t have people who are doing bug triaging (in the same way like Myriam explained is happening for Amarok), you won’t have people doing L2.

         1. no I don’t think so, I think we would have more people doing second level support than triaging bugs. It’s easier to recruit people from the forums.

            1. OK. I think the best thing to do is to try it out. We can speculate in the comments as much as we want, but we will only know if it really works when it is actually tried out.

7. Not to sound pedantic, but wouldn’t developer bug reports have low entropy and end user bug reports be high entropy? Low entropy being lots of ordered, useful information and high being much less so.

   1. Yesno.
      Entropy as introduced by thermodynamics is simplified to “disorder” what in a way is accurate but not appropriate, since you’ll link it to chaos and think of your room or desktop.

      It might not be obvious, but “disordered” systems contain more information than ordered – think of a white paper. Very ordered. Information: “it’s white”
      Now think of a lot of black dots on it. If they’re in a grid that carries the information: “white paper with a black grid” – if they’re in “random” appearance, they encode any kind of data (bitwise 😉

      This becomes more confusing because of the concept of “noise” – because noise actually has a high entropy (by the original definition) but when you talk about noise in information, you think of signal to noise ratio, ie the uniform “white” noise carries no significant information – it’s the white paper and the signal are the black dots =)

      Enter information theory. It does neither help much that Wiener and Shannon defined “entropy” contradicting but also the term is rather not used in Germany and if you lookup “Information density” or “information containment” in a dictionary, there’s either nothing or “entropy”.

      Now, whatever quarrel Shannon and Wiener might have had or what might be tought in schoolbooks wherever you live, Shannon’s is the more relevant work and originally focussing on communication theory the bottom line is that lower entropy means more redundance. ie. entropy is a measure of _relevant_ information compared to the predictable information.

      Feel free to read on in WP 🙂

      1. And they all lived happily ever after…!

         Thanks for the clarification. Just goes to show this blog isn’t all just about gossip and tittle tattle after all. 😛

8. Interesting idea, I’d love it. I find myself between bugzilla / forums more often because some bugs are more general idea’s that would benefit from a forum instead.

   In fact, in KMess, we always had the methology to use a forum as frontend for the user questions/bug reports, and then we entered clear tasks in the trac instance. It kept our tracker quite clean, and kept developers productive.
   (some food for thought: http://trac.kmess.org/wiki/Tickets%20usage)

   A forum also allows more personal response to a user, and making a good explaination instead of “Closed as WONTFIX” what really solves the technical problem, but not necessary the feeling the user got stuck with in the first place.

   so +1 🙂

9. This only helps users if you find enough people doing all that level support.

   If you do not find enough people for the support levels closing bugzilla will simply result in broken communication with the users.

   The more levels you introduce, the easier the line of communication breaks due to missing links, i.e. lack of people doing the xth level support.

   I’m curious how it will work for kwin as the first project to implement this idea. Since you claim it’s more efficient than bundling all this communication in bugzilla kwin devs should be able to do all the levels support and still save time.

10. As an user with no major technical knowledge, trying to report bugs, I’d say YES, but only if you, developers, agree to a) watch user forums; b) answer threads; c) look for genuine trouble in forums, and d) request mods for timely bug reports.

    Otherwise, we would end with buggy software and with mods and developers in a state of “yes, what our user base thinks is crap, we make PERFECT and BUGLESS software”.

    I’m hoping that this work, because a) I don’t feel I have the competence to make proper bug reports, and b) I need a place to post feature requests that will be read by developers. For instance, I think the “Cube” effect for switching desktops and the “Desktop Cube” effect are redundant; the “Cube” effect should get deleted and the desktop switching case should be handled by the “Desktop Cube”. But things like those need discussion.

11. So basically, your proposed level 2 support is what is quite similar to bug triaging, except that you propose to move it out of bko. This has the risk of adding an additional step in the entire command chain, and that step (=person) has to be functioning at any moment. This I feel is an unrealistic requirement for anyone in an organisation of volunteers.
    A few observations here:

    1) Kwin is doing an awesome job in keeping the amount of open bugs pretty much constant for years now. Thank you for that. Given a significant amount of old bugs in that list, I wonder how much a concentrated bug squashing weekend could deflate that list. I would volunteer joining such an effort.

    2) Bug triaging is hard work. I have a lot of respect for largely unsung hero’s like Christopher and Myriam, as well as for the developers that spend a lot of time in the bugtracker. I’m forgetting people here. I’ve tried the triaging here and there last few months, focussing on Plasma. Unfortunately, my available time is intermittent (so I would fail as Level 2 support because of that). But it showed me that it only a few more people are needed to keep the bugs triaged. The only thing one needs for it is a reasonably up to date KDE, and a decent user-level knowledge.

    3) Myriam proposed a tag ‘triaged’ for bugs. I think I agree, or at least a policy how to deal with. Given the amount of work that is left todo, we can have a fairly stringent policy. There are many bugs that are so minuscule that I’m tempted to give them a wontfix – but I won’t, since I’m not a developer so I can’t decide. And shouldn’t. A ‘triaged’ tag would be beneficial, because it may mean: This bug has been checked for sanity, reproducability and duplicates, if a dev has some bugfixing time, feel free. It would also give a signal to the reporter that his bug is taken care of.

    4) A lot of triaging effort goes in closing and hunting duplicates. I guess a fair amount of this can be solved by setting a minimum version for bug reports, for instance always the latest major version. The likelihood of still finding a new, relevant bug in 4.6 or 4.7 is rather low.

    5) I fully agree that wishes in bko make no sense. The forums are much better suited for that.

    6) Stack exchange could work very well for user support. Since it is question driven, and not knowledge driven, it tends to be better suited than wikis.

    7) Almost 20% of the reports in Plasma have had no comments in the past 12 months. Maybe a bot asking quiet bug reports whether the issue is still there would help?

12. One nice feature the code.google.com issues tracker has that might be helpful here is having a customized template with questions relevant to the product — for example for mod_pagespeed we ask about what Apache version and configuration the reporter has — and it correspondingly would be helpful to make sure that all KWin reports have information on what OpenGL drivers people have, etc. Actually, now that I think about it, surely Dr. Konqi could fill in some of that automatically, perhaps in an app-dependent manner, too?

13. I agree with Martin’s approach regarding the bugzilla.

    I don’t think that Martin’s idea makes the bugzilla closer.
    Still the users will be able to report their issues and that’s
    the important one, the fact that they will report the issue somewhere
    else doesn’t make us closer us a project.
    But this is my personal opinion everyone, I can also be wrong.

14. It seems like you’re trying to solve 2 different problems here:

    A) Users who file support requests disguised as bug reports won’t get the support they were looking for.

    B) Low-quality bug reports clutter up the bug tracker and make it difficult for developers to use it as an internal “TODO management” tool.

    In both cases, I’m skeptical whether “let’s close the bug tracker for users and let the forums handle it” is a good solution.

    It seems to me like A could be handled by a warning message above the bug report wizard (and if users disregard it, then that’s their problem).
    And B could be handled by introducing appropriate tags for bugs, so if as a developer you’re only interested in the triaged or developer-reported bugs, you can restrict your bug searches to the relevant tags.

    This way, level 1 and 2 supporters can simply add or remove tags fro reports, rather than having to write new reports themselves.

    Also, your claim that a forum would be better equipped than a dedicated bug tracker to handle the incoming flood of possibly low-quality bug reports from users, doesn’t convince me. Especially:
    a) Users wouldn’t have a bug report wizard to guide them.
    b) Bug trackers are optimized for easily and dynamically categorizing and selecting (or “hiding away”) bugs based on certain criteria (“tagging” and “advanced search”/”saved searches”) – forums are not.
    c) The forum contains lots of general discussion which is *not* bug reports, and which would interfere with them and vice-versa (e.g. when users are trying to search if their bug has already been reported).

    The only upside I can see for for utilizing the forums for level 1, is that it would be easier to recruit “triagers”.

    1. the two problems you identified are not the real one. I would phrase the problem like the following:

       “Users think they found a bug, but in truth they were seeking for user support without noticing it”

       that results in the two problems you describe, but it’s a quite fundamental thing. If we get the users to not thinking they found a bug, but that they need support (whether it’s a forum or something else doesn’t matter) will really help them. If the problem they have cannot be solved and turns out to be a bug it should be entered in the bugtracker. That way the user can still check whether it is a known bug.

       It’s quite important to see that I don’t want to replace the bugtracker by a forum. I want to get the bugs into the tracker and the support out of the tracker. The issue I want to solve is the currently incorrect usage of the bugtracker.

       1. But I am not convinced that the solution you propose is not relying on people that are simply not there – the second line of support.

          Although I fully agree with you in a fundamental sense, would the problem be partially solved with a more aggressive triaging of bugs, and devs only touching bug reports after a few days of fermentation? Yes, help requests would still be out of place, but at least such rules make it less bothersome to the developers.

          1. we have tried getting triagers more than enough. I have given up the hope that some magic day hundreds of users will start to appear in a technical oriented application and clean it up.

             That’s one of the points: we need to try new ways to get people involved and improve the situation. Sure it’s possible that it won’t work, but that’s not worse than what we have now and opening up the bugtracker is always possible.

       2. What if you don’t actually close the bug tracker, but explicitly tell users to only submit bugs after they’ve discussed it on the forum (or if they’re really sure it’s a bug, e.g. in the case of long-term power users spotting obvious regressions)?

          This way, you wouldn’t even need official “level 1” triagers, users could simply discuss potential bugs / support issues among themselves on the forums, and then file a bug request once it has been agreed that it makes sense.

          And the triaging work in the bug tracker would become much simpler (fewer bug reports, almost no duplicates, bug descriptions containing link to forum thread where other trusted users may have already confirmed the bug).

          Of course users could still choose to ignore this process and just continue to file everything to the bug tracker directly, but one can make it clear to them that if they do, the chances of their bugs being triaged (and hence a developer ever looking at it) decrease dramatically – and it would be *their* fault (for ignoring the rules), not the triager’s/developer’s (like many users see it in the current system).

          But still, I’m concerned how you would remedy the loss of bug-report-assisting functionality (guided wizard, specialized search functionality, etc.) when moving level 1 from a dedicated bug tracker to the forums.

          Expecting users to first go to the bug tracker and search if a similar bug report already exists, and then leave the bug tracker and go to the forums to report their bug, isn’t very realistic imo.

          1. Expecting users to first go to the bug tracker and search if a similar bug report already exists, and then leave the bug tracker and go to the forums to report their bug, isn’t very realistic imo.

             That is something I don’t expect and it does not work anyway. The search provided by bugzilla is so bad that you cannot search with it. I know what I’m talking about because I have to find duplicates. My way to do it is either using Google search or searching over my bug mail folder. But bugzilla’s search does not find the duplicates.

15. unfortunately I don’t see this as a solution. I’ve reported say, a bug for systray, been told it was a QT bug and go report it to QT. Your fellow developers are not good enough at passing things down the line for this to be a solution.

    1. what you have to see is that the current workflow is so broken that we don’t have the chance to pass bugs along. By getting the bugs out of bugzilla, I have the hope that we will be able to do more of these jobs.

Comments are closed.