This blog post is for you if:
- you want to help to improve Dolphin, no matter if you have programming skills or not,
- you want to know more about how quality assurance in a free software project works,
- you’ve always wanted to contribute to KDE, but could not find a good place to get started.
Like every software project, Dolphin unfortunately has bugs. Bug reports are filed by users at bugs.kde.org, then we (the developers) read the reports and fix the bugs, and everyone is happy, right? Well, it’s not quite that easy.
Carefully reading a single bug report, including all comments, extracting all relevant information, and trying to reproduce and then analyze the bug usually takes quite a bit of time. It gets worse if a report is incomplete, i.e., if important information is missing, or if the bug just cannot be reproduced on the developer’s machine for some reason. Now consider how many open bug reports there are (currently 305 for Dolphin, not even mentioning wishes), that new bug reports are filed every day, and that lots of comments are added to the existing reports. Maybe you start realizing why we spend a considerable amount of time managing bug reports instead of fixing bugs, and why we are nonetheless far from being able to give every bug report the attention that it deserves.
To make working with the bug database easier and more satisfactory for everyone (users, developers, and also potential new contributors), I’m trying to revive the Bugsquad effort and organise a joint bug triaging event. The goal is to go through all Dolphin bug reports and improve their quality by
- making sure that all important information is in the report and that the summary is meaningful,
- assigning all Dolphin reports to the right components (right now, most reports are in the ‘general’ component),
- marking bugs that can be reliably reproduced with the ‘reproduceable’ keyword,
- closing bug reports that are not valid any more, and
- requesting additional information from bug reporters if necessary.
It’s very easy to take part: just make sure that you have KDE 4.9.2 (a 4.9 or master branch checkout is fine as well), head to the wiki page on Techbase, read the instructions carefully, pick a batch of 5 bugs, go through them one by one and check if anything about the report can be improved. Always be friendly when you add a comment – keep in mind that the bug reporters have also sacrificed some of their free time to make Dolphin
better. Ask any questions in the forum thread that I have created for this purpose. I’ll check the forum regularly and try to help (please use this forum thread only for bug triaging-related questions, for nothing else, in particular not for reporting bugs). I don’t use IRC much myself, but you might also be able to find people who can give advice in the #kde-bugs channel (which is also strictly for triaging-related discussions only).
You’ll obviously need a bugs.kde.org account and ideally a KDE identity account, which works both for the wiki and the forum. Unless the permissions of your bugs.kde.org account have been upgraded, you can only add comments and not make any other changes (like changing the component or the version), but we want to double-check each other’s work anyway, so just add a link to the bug report and a short comment to the appropriate section of the wiki page, and someone else will have a look and make the change for you.
A final remark: I know that some people might think that I should better spend my time fixing bugs, rather than organizing a triaging event, because there are quite a few high-quality bug reports which I could start working on right away. However, I believe that a joint effort to go through all bug reports will not only make the work of everyone involved with Dolphin more efficient in the future, but also has the potential to attract
new contributors (as I said in a recent interview for Behind KDE, my own involvement with KDE started with a bug triaging event and fixing a small bug shortly after that). Therefore, I am sure that this organisational effort is a good investment.
Thanks for reading this! I’m looking forward to a productive collaboration – I’ll also take some batches myself next week. I don’t know how long it will take to go through all bugs, but I’ll post a bug triaging summary here when we are done.