On the kde-core-devel mailinglist we currently have a very interesting discussion about how we use our bugzilla installation and in general user support. The first interesting thing to notice is that there are different developer groups who have different expectations from bugzilla and who see it being used differently.
- library developers: users of libraries are developers. Bug reports are useful and have a high level of entropy. In general the developers would like to have reporting bugs as easy as possible. Examples are KDE frameworks
- developers of advanced applications: the user group is very specific and the user base is quite experienced. The amount of bug reports is still rather small and reports are very useful to the product. Examples are Krita and to a certain degree KDE PIM
- developers of end user applications: large number of bug reports and most bug reports are user support issues. The entropy is very low and it is very difficult for the developers to find useful information and to fix actual bugs. Examples: Plasma Desktop and KWin
From these three developer groups we can recognize that there are different expectations on what bugzilla is used for: developer tool vs. end-user support tool. From the discussion it seems so far that all groups want to have bugzilla as a developer tool, but that the first two groups also consider it to be a user support tool.
Bugzilla is no end user support tool
For KWin our bugzilla installation is actually abused as an end-user support tool and given what we see I don’t think that bugzilla is suited for end-user support.
- Successful solved problems cannot be marked as that. It is not a “fixed” bug, but in fact an “invalid” bug.
- Users cannot find their issue as successful solved issues would be marked as “invalid”
- user interface is too technical for user support, e.g. “severity”, “priority”, etc.
- useful information is hidden in mess of useless information, e.g. duplication notices
- moderation is not possible
- user interface is tailored towards a defects management system
- crash information hide the workarounds to prevent crashes
- release announcements state how many bugs have been resolved
Given that I think we should make sure that user support issues do not end up in the bug tracker. It’s nothing the users want to use. Given the bugs we have in KWin I see that users think that they found a bug, but in fact it’s just a user support issue. We have to bring users to the right tool to solve their problems without introducing more work for the developers.
First, Second and Third level support
At the first stage for end-user support we need (and have) a working first level support system. This can and should be distributed over many channels like forums, mailinglists, IRC channels and maybe even phone support. First level supporters take care about the issue and help the user. Many problems can be solved directly – e.g. by telling them which option to set.
In case the first level support is unable to solve the problem the second level support has to be involved. The second level support verifies that the first level support tried everything to solve the problem. If that is the case the second level support investigates whether there is a real issue (aka bug) and whether it is already known on the bugtracker. If it is not the case the second level support informs the third-level support about the issue by opening a bug report.
The third-level support are the actual developers. They have a look at the issue and verify whether this is a bug or not. If it is a bug they accept the bug report and inform the user about it in the initial first level support tool that the development department took over the issue.
If it is not a bug the third level supporters provide the required information and pass the issue back to the second level support. These supporters use the provided information to update the documentation for the first level support so that if the problem arises again it is well documented and the first level support knows how to handle it without involving the first level support.
How this could be implemented?
In my opinion the best tool for first level support is a forum, which we already have and which works quite well. The second level support is mostly missing. A way to inform second level support needs to be introduced. This could be done by having a tool to create a bug report from a user support thread assigned to the second level support.
In this bug report the second level support can handle the work task oriented. If they need to involve the third level support they just inform them by setting a flag. The third level support can then investigate the issue and in case there is a real bug they open a bug report for this specific task and block the support report for it.
Advantages of the approach
The biggest advantage is that the developers only get real bug reports and each bug report has all the required information as the report is in fact created by the developers. Only valid bug reports will enter the system.
In general the bugtracker will be used more task oriented: one task for investigation, one task for fixing the bug and so on. Bugzilla is very suited for such work as it is possible to add flags, introduce bug dependencies and if required duplicate bugs. It would allow us to use bugzilla to manage our work which is currently not possible.
The users would always be informed about the state of their support request. They would get the feedback that their problem is under further investigation, that a defect support has been created, that it has been fixed. It would be a much more transparent process for the user.
As there is always the feedback to the second level support state the end user and first level support documentation would get updated increasing our quality not only in the software but also in the documentation.
Disadvantages of the Approach
The biggest disadvantage is clearly that this would result in a closed bug tracker. For many people involved in free software an open bug tracker is the ultimate tool. Here I think the advantages for all users are overwhelming and the closed down bug tracker is a small price to pay.
Another disadvantage is that it requires creating multiple bug reports and re-entering data for the same issue. Again I think it’s a small price to pay especially if we go to a task oriented approach and have everything nicely linked.
I hope to see a nice discussion in the comment section of my blog post. Hopefully many people see the advantage in this and I would love to try such a new issue tracking workflow for KWin as an experiment for the complete KDE community.