Comment 43 for bug 329659

Revision history for this message
In , moenchmeyer (rm-anracon) wrote :

(In reply to comment #34)
> (In reply to comment #32)
> > Reactivate the auto-expand - and please, do it at once !
>
> While I understand that you may consider this very urgent, some may take
> offence to the tone, so consider software language.
>

I apologize for my bad English, no offence was intended. I expressed myself badly. And probably there is no one to blame.

I wanted to say that I as a normal user whose daily work depends heavily on Kontact/Kmail have the whish that this kind of "regression bug" is solved as soon as this is technically possible. And I think I have good reasons for my whish. I have tried alternatives but I find that the situation before the "bug" was better and that the suggested alternatives do not support the user's workflow as well as the program already did in the past.

I hope this is agreeable ?

I know very well that there are a lot more things for a developer to consider than I as a standard user see and focus on. And I accept that the process for error correction or feature changing takes its time especially with respect to open source products.

However, when you depend on an open source product in a productive environment and you have to deal not only with one but several time consuming "regression or feature problems" again and again - it is no funny situation either. And it makes the release policy within a company very complicated. Therefore, I can e.g. very well understand the points Martin Lüchem describes.

Sometimes some problems remain open for months and over major release changes. And there are some classes of "little" bugs that can drive a user to the point when you just want to give up and just begin using another program. I may say this from over 10 years experience with Opensource enviroments.

I know this kind of discussion is off the purpose of this bug tracker - but maybe it helps to see why the continuous handling of small "bugs or features", which change a product from good to worse in the eyes of a user, is so important. So one more example :

I, too, ran into the Akonadi related problems with the adressbook - it took me hours to understand what happened why and how to resolve the problems with the adress book. Eventually, I only understood what was going on by following a continuous discussion of a really desperate (!) user with some KDE developer over several pages in a forum - until the developer understood why the user had a problem at all and the user understood that the Kontact Akonadi adressbook presently was not intended to be used in Kmail and that he had to generate separate "old" adressbooks for Kmail. To circumvent the problem then was simple - but you ask yourself: how could such fatal misunderstandings come about at all? Why is the user suddenly confronted with the consequences of a "design" decision which he has no chance to understand or handle but which is fatal for his daily work?

At that point in time the Akonadi problems on a test system had already influenced a key decision in my company not to move to KDE 4.4. So problems which may seem small and limited to a developer can have much wider effects than they may expect.

And therefore I very well understand why some users want to see a "product manager" as Martin Lüchem describes it.

But again .... I am really sorry for the unintended harsh tone .....