On Sunday, October 02, 2011 11:27:33 AM Anne-Marie Mahfouf wrote: > 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.
See http://blog.lydiapintscher.de/2011/10/03/teaching-the-next-adas-join-kde- for-ada-lovelace-day-tutorials/ The "How to Help with Bugreports" IRC tutorial is a great way of getting involved a step further reporting bugs and help KDE. I hope you'll be several to join. Best regards, Anne-Marie >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
