[Kde-pim] Cleaning up obsolete features

[Kevin Ottens]

Hello,

I think there's a point which needs addressing in here so replying separately 
to it.

On Saturday 01 August 2015 14:32:27 laurent Montel wrote:
> [...]
> But removing code as ' "all headers" header style ' will not cleanup code or
> makes it easy to maintain kmail.
> It's just a little class in messageviewer.

It'll improve usability though. As Volker mentioned there's no point in 
keeping it as it doesn't make sense nowadays, so why put that in front of a 
user in the first place?

Anyway, this is just an example, I don't want to focus too much on it, I'm 
more interested in the broader issue.

> [...]
> But for me the real problem is not to reduce code, but perhaps be able to
> have more developers and we need to have developer will work during all the
> year and not just during sprint or akademy.
> 
> Because if we remove some part of code but we don't have more developer I
> don't see how it will improve situation no ?

The thing is that in reality, it's not orthogonal as you present it here.

If you want more volunteer developers you can't just simply claim "hey come 
and help" praying they'll indeed come and help. You got to change first and 
have a code base which is pleasant to work with. kdepim has been notoriously 
bad at that for a long long while now. There's three main reasons for that:
 1) it is very old code which often ends up being overly complex;
 2) it tends to collect random features for no valid reason, often a by-
product of not having a defined vision;
 3) it has to deal with a complex domain (PIM is a complex field).

Only the complexity induced by (3) is valid and likely not a barrier for 
developers to join (probably even motivating to some extent). The complexity 
induced by (1) and (2) on the other hand makes it extremely hard for 
developers to be motivated to help or stick around for a longer time.

The work on the vision and the moves to streamline the code base (removing 
some of the features in the process) are aimed at addressing the unneeded 
complexity generated by (1) and (2).

If it becomes more pleasant to work with that code base again, it'll be easier 
to focus on really polishing the features pleasing our users more and it'll 
remove a barrier for developers to join.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150802/d753a47e/attachment.sig>
-------------- next part --------------
_______________________________________________
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/