On Wednesday, September 28, 2011 01:46:14 PM Bart Kelsey wrote: > Hi folks, > > I'd like to draw attention to the fact that KDE's bug triage process is > lacking. > > It's frustrating for users submitting bug reports when an easily > reproducible bug sits in the queue, without even a comment, for six > months. For the record, I'm referring to this bug report here: > > https://bugs.kde.org/show_bug.cgi?id=270105 > > I have, for the record, already posted a message to plasma-devel about > it, and I'm mentioning it here because I believe it's indicative of a > larger problem. > > From my understanding of C++ and Qt, this bug is most likely very easy > to fix for someone who knows the code base. Even if it's not, though, > it would require a trivial amount of time to confirm it, leave a brief > comment, and mark the bug as new. > > My question, ultimately, is do you really want users to report bugs? > If so, there ought to be a process in place to make sure the users who > report the bugs know that the bugs have at least been looked at by a > human being (and preferably triaged). I realize this isn't exactly a > fun or interesting job, but for a large FOSS project like KDE, it's a > necessary one. > > Regards, > > Bart Kelsey > The bug refered there is not really a bug. It is a usability wish. In my opinion, such a wish should be accompanied by a strong use case. Do you often remove panels? when do you do so? why do you remove them "accidentally"? same for widgets. My use case is that I take time to set up my workspace when I install my distribution and then occasionally I need for example a new activity that I set up. The rest of the time I use my machine as it is. When I do those setup, I dedicate some amount of time which includes trial and error time. This is my use case. Yours can be different.
As for general bugs: - the number of reported bugs is too large for developers to deal with it. We addressed this by trying to make the reporting smarter and by setting bugsquads days/weeks to "triage" bugs. Triaging means moving the bug report to a new state: - identify duplicates - reproduce the bug and mark it as CONFIRMED - write clearly the steps to reproduce it are 3 important states but there are others. Recommanded reading: Quick reading: http://techbase.kde.org/Contribute/Bugsquad/Guide Bug Triaging: http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging A bug's Life Cycle: https://bugs.kde.org/page.cgi?id=fields.html Setting up a bug day: http://techbase.kde.org/Contribute/Bugsquad Users do report bugs. Developers do fix bugs. To achieve better results, we need the intermediary: users participating in bug triaging. The last bug days I participated to, we were only a handful of people (and maybe not a complete handful even!) and I was very discouraged to carry on. Maybe we lacked promotion of it, the one regarding kdepim also was difficult to triage because technical. I urge you to be positive and help with an hour or so of contribution during the next month. I am willing to set up some week-end bug days, I am sure members of the bugsquad also are. But we need help otherwise it's just too much work when yo uare only 2 people. Please stay tuned to Planet KDE in the next days and volunteer to participate to any bug crushing effort that will be planned. Thanks for reading, Anne-Marie >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
