[Kde-pim] Marketing blocker collection, DEADLINE: 2013-03-10

[Martin Steigerwald]

Hi Georg,

Am Sonntag, 3. März 2013 schrieb Georg C. F. Greve:
> To clarify: This is not about issues or our pet peeves, it is about
> things  that are BLOCKERS for end user perception. So we're talking
> about things that would make someone immediately stop using KDE PIM and
> never come back.
> 
> Submission to that list is open until 2013-03-10 to kde-pim at kde.org.
> 
> Anything sent elsewhere or after that date will not make it to the list.
> 
> The list will then be triaged for things that are
> 
>         BLOCKER:                  Data loss, fundamentally broken
>         MAJOR:            Extremely annoying, but not causing irreparable
> damage NORMAL:           Must be fixed as soon as possible
>         MINOR:            Nuisance, but not really broken
>         IMPROVEMENT:  A better way of doing this

I have the following in mind together with the priority I think would be 
approbiate. I do not know whether all of the blockers I list are still 
present, as I did not yet come around to test KDEPIM 2. Feel free to discard 
those that are gone.

I thus often ask if there is any such issues still left. In case you are 
affected by such an still existing issue or know some by other means, please 
state it in a reply and if possible provide bug numbers. I may do some 
investigation myself by scanning through recent mails or bug reports.


1) BLOCKER: Any kind of bug, where deleting the complete Akonadi meta data 
causes Akonadi or KDEPIM to loose any amount of the original PIM data of the 
user like the original mails in local directories, mails stored on IMAP 
servers, calendars locally and remote. Two things come to mind:

a) Filter rules that filter to wrong folders after deletion of Akonadi meta 
data.

b) Any expiry settings in the configuration. Could not happen currently, as I 
understand Andras, cause these settings are in the Akonadi database. Its a 
configuration data loss tough, but thats still way more acceptable than a 
original PIM data loss.

c) Any synchronisation issues between Akonadi data and original PIM data? 
Are there any still open? Is it safe for new mails to appear in any maildir 
folders for example?

Ground rule: Original PIM data is authoritative. If Akonadi´s view of this 
data does not match reality, Akonadi has to adapt. Of course on temporary 
inability to access the original data, Akonadi better keeps its metadata 
instead of deleting it all. 

PIM data is *personal* user data. Keep it safe. Developers and users discuss 
in this thread currently on how to fix remaining issues here.


2) MAJOR: In case Akonadi still doesn´t view the real situation, its 
important to provide the user with an easy way to tell Akonadi to update its 
metadata. Due to bugs I think it can happen that a mail that should be 
shown, is not, or a calender update does not get triggered. Ideally such 
bugs are fixed, but until they are, I think its important to provide the user 
with an option to tell Akonadi/KDEPIM "This is not current state, something 
is missing here, please resync."

Of course according point 1, Akonadi has to keep the original PIM data that 
it currentl does not see safe. Ideally this would go as far as that on 
deleting a mail folder where Akonadi does not see all mails, it does not 
delete that folder. It may delete all mails Akonadi sees, cause the user 
told Akonadi so, but ideally it keeps the mails, Akonadi didn´t show to the 
user safe. In that case I think its important to provide the user with an 
error message and suggestion to resync the Akonadi metadata with the real 
situation or if that does not help report a bug.


3) MAJOR: Mail address auto completion in KMail does always work and 
includes addresses from addressbooks and not just recently used mail 
addresses.

Reason: It is very annoying to have to dig out a mail address stored in 
addressbook manually. I currently have to do with KDEPIM 4.4.11 in Debian 
Sid, cause somehow this completion does not work from addressbook anymore.

Are there any such issues still left KDEPIM 4.10.1?


4) MAJOR: Any hogging of the complete machine for extended periods of time 
except for initial sync or resync and really big user operations liking 
moving 30000 mails from one folder to another.

But even for initial sync and really big user operations the applications 
themselves IMHO should always stay responsive. From what I understood that 
was part of whats Akonadi was made for.

Are there any such issues still left?


5) NORMAL/MAJOR: Any annoying conflict resolution windows that are either 
unnecessary or made in a way that makes it difficult for the user to 
understand. Same for any other irritating messages to the user that may come 
in in a big amount at a time.

Are there any such issues still left?


6) MINOR/NORMAL: Any other not regularily appearing message to the user that 
is difficult to understand.

Are there any such issues still left?


I do not know of any improvement that qualifies as a marketing blocker. The 
functionality of KDEPIM 4.4.11 already is *great*. I think a lack of 
features is not the issue here. Sure, some things may be able to be done 
better, but I do not know any marketing blocker here.


Last kudos to the KDEPIM team. I still have the KDE Commit notifications for 
KMail and and I often read how many bug fixes you make. I really appreciate 
the great amount of stabilization work here and elsewhere in KDE SC.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/