[Bugsquad] KDE PIM Meeting Rumors

Mon Feb 20 21:51:24 UTC 2012

On 2012-02-12 10:42, Anne-Marie Mahfouf wrote:
> 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.
>>
>
> Hi Jeroen,
>

Hi Anne-Marie, and Christophe,

I hope you don't mind I'm replying to both your emails in one go.

I reckon indeed a lot has improved in terms of bug-triaging, lately. 
You mention both the number of open reports is down, and bug reporting 
tools have vastly improved.

In terms of bug-triaging, more so then in "issue tracking management" 
if you will, naturally it is about the quality of bug reports (helping 
reporters put in the relevant information), and the usefulness of each 
report against what could be considered the currently supported 
code-base(s) (examples would be the kmail1 vs. kmail2 bugs).

I concur in that with the bug triaging effort, communication with the 
reporter as well as the developer(s) is key to success.

I love bug triagers - they make the part of my work that is development 
a lot easier ;-) In the Fedora Project, we call the bug squad 
"bugzappers", BTW.

If you'll permit me, however, the other purposes of running an issue 
tracker seem to be overlooked, or undervalued. One side, for example, 
which I'm afraid is currently grossly underestimated in value, is having 
the issue tracker function as a developer's TODO list and a planning 
tool, as well as an overall health indicator.

On 2012-02-12 10:42, Anne-Marie Mahfouf wrote:
> You said the problem was mentioned at the meeting, did they mandate 
> you to start an action?

It turns out many KDE PIM developers do not look at Bugzilla for things 
to do. Having looked at the ticket list for kmail I concur Bugzilla at 
this very moment is not a very useful tool to them.

I think this is, ultimately, significantly damaging to the overall 
reputation of the KDE PIM stack, and therefore its growth. Ask Jos 
Poortvliet about how "Akonadi" and "Nepomuk" have become dirty words and 
should no longer be used in terms of marketing.

The KDE PIM developers that have attended the conference seemed to 
concur that the tickets in Bugzilla are messy, too often of poor quality 
and in and by large with too many in volume. This is *not* to say 
ongoing efforts to improve the situation are bad, nor is it to say they 
are ineffective - its just that so far, for the KDE PIM developers at 
least, the efforts seem to not yet have been fully effective.

One surprise that hit me was that I was not able to close off bugs - it 
seems someone needs to specifically apply to be added to the 'editbugs' 
group, which -I was told- was cautioned as the result of attempting to 
combat some poisonous people changing the status on bugs all the time. 
Contrary to bugzilla.redhat.com, on which the Fedora Project runs their 
issue tracker as well, and bugzilla.cyrusimap.org, issues.kolab.org and 
bugzilla.kolabsys.com, neither of which has any such problems, it seems 
to me bugs.kde.org is overly restrictive.

I would love to be able to free bugs.kde.org up again, and take those 
poisonous people into their own little corner of the universe if 
necessary still. Bugzilla provides ways to do this, FWIW.

On 2012-02-12 10:42, Anne-Marie Mahfouf wrote:
> 3) you write that you are involved in bug triaging for other
> projetcs, maybe you have a methodology which we could learn from.
>

One of the things I do for another project, Cyrus IMAP, is to help 
define and manage a Bugzilla workflow - what every state is supposed to 
indicate, and what the conditions are to put a ticket in such state.

I've done this in an outline, which was accepted by the project's 
frequent reporters, and the project's most prominent developers - it's 
been an evolving document ever since, of course, that is to say the 
balance to strike between both sides of the equation -what is still 
useful and easy for the one party, as well as the other- is tricky 
business.

Furthermore, let me state that, no matter what happens, I do not have 
any sort of control over the Cyrus IMAP reporters/developers - or where 
they spend their time - like I don't nor would have over the many KDE 
developers.

My trick is to find ways to make all of what makes a software 
development project run smoothly, in ways that are satisfactory (or 
increasingly satisfactory) to all parties involved, using the utilities 
at its disposal optimally.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> On Saturday 11 February 2012 23:26:18 Jeroen van Meeuwen wrote:
>> 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.
>
> Yes, that's true for any large and successful project :-)
>

Yes, this is true.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> We're not in such a critical situation. The stats page reports we 
> have less
> than 22000 reports opened. It's wayyyyyy better than a few years ago.
>

Way better than a few years ago is improvement, but sure is not 
"problem solved". I'm curious what the problem is, as bugs reporting 
University of Washington IMAP disconnecting a first connection upon 
opening up a second client with the same user, seems to be regarded to 
as a valid kmail bug - still open, with the latest comment from 2004.

You'll understand my concern if this bug is on the first page of bugs 
still open against kmail.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> The first step was to prevent useless backtrace. (...snip...) If 
> drkonqi detects that the bug is already
> reported, it doesn't allow creating a duplicate bug (...snip...).
>
> This seems to work nicely. I've seen less report when 4.8 was
> released than in any version since 4.1.
>

This should indeed (drastically) reduce the number of duplicate or 
useless new tickets.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> Now, the not-so-bright side:
> - Wishlist bugs:
>   * Triagers can't read in the app maintainer mind and deal with
> these reports easily

True, but it seems Bugzilla is not used as a planning tool right now. 
One can imagine postponing the wish for pink ponies 'till the end of 
days, and meanwhile maintaining a clean "this is what you, the 
developer, need to be working on next".

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
>   * Reporters usually want things that fit their workflow without 
> first
> checking if it can be useful for anyone else (I did a quick kmail1
> wish review some months ago, if every wish was granted, it would have 
> ~ 50 new
> buttons and ~80 new options)
>

To put it bluntly, I think the appropriate mantra for wishes is always 
to "put up or shut up". Processes can be defined in order to allow 
someone (who cannot do the work themselves) to define the feature 
requested in a way that is then also subject to review, before it ever 
actually ends up on a developer's plate - who, in turn, cannot read the 
reporter's mind, of course.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> - normal bugs:
>  * Reporters usually don't search if their issue is already reported. 
> It's
> probably not easy enough to guess what you should look for (the
> simple search is too simple and the detailed one is too complex).
>

In part, this will always continue to be the case. Updating 
(upgrading?) Bugzilla would help, as its search interface is enhanced in 
series 4.x. I'm not sure what version you run today, and I've heard 
there's quite some (significant?) modifications as well, so this is an 
item on my agenda to work out with the system administrators.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
>> 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.).
>>
>
> Good idea, do you want to focus on particular bugzilla products?

Yes - all of them.

The first ones on my hitlist are the open ones with the last change to 
them applied the longest ago ;-) I'm thinking a two-four week reminder 
on needing to re-activate the bug is a polite way of indicating it is 
probably going to disappear soon enough. I think someone might get into 
the doubtful region somewhere around ~2009, or three years of no 
activity on the report, maybe, but it depends on the activity prior to 
the last comment as well.

On 2012-02-13 18:44, Christophe Giboudeaux wrote:
> To assist you, we have a small triaging guide there
> http://techbase.kde.org/User:Blauzahl/How_to_triage_bugs (note for 
> self: it
> needs some updates and to be moved to a better location)
> We're also on #kde-bugs if necessary.
>
>> 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.
>>
>
> Can you clarify 'our developers' please ?
>

Sorry, I was overzealous in referring to the developers working for the 
two parent companies to Kolab Systems as "our developers".

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08