[Bugsquad] KDE PIM Meeting Rumors

[Anne-Marie Mahfouf]

On 02/11/2012 11:26 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
> Hello there,
>
> While I'm relatively new to the KDE community, please allow me to give a brief
> introduction as to who I am, and what I'm doing. Your favorite search engine
> has all the details you need.
>
> My name is Jeroen van Meeuwen, and I'm originally Dutch, though living in
> Cardiff, Wales, United Kingdom. I've always been, primarily, involved with
> Fedora Project related endavours, and I'm currently working for Kolab Systems.
>
> As a Free Software enthusiast, having operated before, and currently operating
> a few bugzilla instances for Free Software projects, I'd like to help you with
> what has been mentioned here, during the KDE PIM meeting in Osnabrueck, is
> quite a serious problem; the bugzilla installation for KDE seems to be
> overgrown with cruft, that either needs review, or needs additional
> information, or needs to go away and disappear.
>
> Currently still involved in making such happen with the Cyrus Project
> (Carnegie Mellon University, responsible for Cyrus IMAP and Cyrus SASL), I'd
> like to think I can help you clean up Bugzilla (workflows, triaging, etc.).
>
> I would like to know if there's currently a process in place to make sure that
> Bugzilla is *the* location for our developers to look for things to do.
>
> Kind regards,
>
> Jeroen van Meeuwen
>
Hi Jeroen,

Nice that you want to get involved helping the bug triaging effort.

Recently, just before 4.8.0, the Plasma team did a special effort to 
triage Plasma bugs and we get the numbers down in an impressive way. 
This was done with the developers involved which is in my opinion the 
main point for triaging KDEPIM bugs. We first triaged crashers then we 
triaged reports products by products (applet foo, applet bar,..). 
Coordination tool was a wiki page where we put our nickname + the 
product we triage and we also put links of report we are not sure about 
so the devels can look at them.

At Google Code-In, a few tasks were to triage kmail1 wishes and see if 
they are still valid for kmail2. 2 or 3 students triaged 40 reports each 
but then someone had to look again as the students did not have the 
rights to close bugs. I did the work but it took me several hours. 
However the developer commented on the reports that were confirmed for 
kmail2 and fixed some which was very positive.

Anyway, all this to say that
1) triaging bugs should be done by products (kmail, ...) as we did for 
Plasma (we have 2 triagers who got involved at that time and are still 
triaging daily several reports each). Sometimes when we do bug triaging 
week-ends we prepare bunches of 5 or 7 bugs for each person to pick and 
go through. It's maybe easier to go through crashers first then through 
similar bugs. A bug triager gains expertize when triaging similar bugs. 
We do not have a real methodology though.
2) involving developers is mandatory, especially for kdepim applications 
which are very technical (lots of libraries involved); personally I have 
great difficulties to triage pim bugs, I don't have the necessary 
knowledge and I am not a pim poweruser. So I get discouraged after a few 
reports. You said the problem was mentioned at the meeting, did they 
mandate you to start an action?
3) you write that you are involved in bug triaging for other projetcs, 
maybe you have a methodology which we could learn from.

Tell us more what you have in mind and I'll be happy to set something up 
with you, I am sure others will join too!

Best regards,

Anne-Marie

PS: Bug triaging is part of making our software of better quality so we 
absolutely need to have a better human infrastructure (== bug triagers) 
than we have! I am currently researching about Software Quality 
Assurance and I intend to propose solutions we could progressively set 
up. A strong bug triaging team would be part of this effort.