[Kde-pim] Cleaning up obsolete features

[Martin Steigerwald]

Am Samstag, 1. August 2015, 01:31:50 schrieb Daniel Vrátil:
> On Saturday, August 01, 2015 12:15:25 AM Martin Steigerwald wrote:
> > Am Freitag, 31. Juli 2015, 22:32:26 schrieb Volker Krause:
> > > On Friday 31 July 2015 15:44:40 Allen Winter wrote:
> > > > On Friday, July 31, 2015 07:26:24 PM Volker Krause wrote:
> > […]
> > 
> > > For KOrganizer, the timeline view and the journal stuff come to mind.
> > > KMail's overly detailed font and color configuration options also look
> > > like
> > > good candidates to me, the situation might be similar in KOrganizer.
> > 
> > Eh, not the journal. I am using it since years.
> > 
> > It has journal entries from 5 years ago or so, at least.
> > 
> > I think removing things should take into account what users use. Of course
> > I don´t know how many other users use it.
> 
> Unfortunately there's always at least someone who uses this or that. This
> way we would not be able to remove anything. Trust me, it's not easy for us
> to do this. Not at all. We spent lots of our spare time working on those
> things, so throwing it away is not something we would do just before we
> can.
> 
> If we want KDE PIM to move, we need to make those hard decisions and reduce
> the size of the code base to something, that the current team can afford to
> maintain. If the team ever grows, we can start bringing these things back.
> But if we want to attract new developers, we need to become interesting
> first. And that will not happen with the code base we have right now. We
> need to do something about it, and this is the result.
> 
> If we can avoid removing something by refactoring it, we will refactor it.
> We don't want to kill features and fucntionality randomly, but we need to
> decide if the benefit outweights the maintenance costs, and if it aligns
> with our vision of KDE PIM.
> 
> Hope this explains it a bit.

Sure, I understand the reasoning behind it.

Still the journal is a special case I think: To the user not having the 
journal anymore appears as data loss. The use case of the journal is to store 
data in there. Without the journal users loose GUI based access to it.

Unless there is some migration or other way to get out the data. I know that 
on my system it is in ~/.local/share/calendar, but I´d also would need to grep 
out and convert the journal entries, separate them from the appointments, 
migrate them to a new application in order to keep access to my computer 
diary. Its similar to using online based apps like these from Google. Google 
removed quite some of them over the time, each time leaving behind frustrated 
users who needed to find other ways to store and access their data. This is 
actually one of the reasons I do use a fat client, I do use local intelligence 
instead of storing things in the cloud.

I understand its all still a discussion.

I think its important to consider the following aspects:

- How many users use the feature? Maybe a survey can help with that. Another 
way would be to ask on kdepim-users and maybe other mailinglists to gather 
some user feedback.

- What is the actual maintenance cost of the feature? If its low, I see no 
point to remove it for easier maintenance.

- Does removing it remove access to stored data? And if so, what is a good way 
to handle this?

And of course whether it fits into the vision. And for that I ask: Is there a 
vision? I am not aware of one. Maybe due to me not being at Akademy. If there 
is, I would like to know about it.

This remembers me about GNOME 3 removing a ton of things. And there users and 
developers made a vote. It has not only one, but two active forks.

I hope it will be possible to talk about things like this at Randa. I will be 
there. I would also like what would be required as maintenance for a feature. 
Maybe for the journal I´d even step in.

Thanks,
-- 
Martin
_______________________________________________
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/