Akademy BoF wrapup, or: KDevelop 4 is about ten years old, how is it going to shine in the next ten years?

[Sven Brauch]

Hi!

TL;DR: Suggestion is to organize a sprint focused on cleaning up KDevelop, 
while being rather generous with removing things and abstraction layers we do 
not think are integral to KDevelop's core goals. Good idea y/n?

Details:

We had a nice discussion today at Akademy in Vienna about KDevelop's future. 
There were about 12 people present, most of which were not active users of 
KDevelop though. Before the BoF, I had some rather extensive brainstorming 
with Aleix, Dominik and Christoph about what the situation is and how the 
future might look like.

In general, the situation in my eyes is that (even though recently it looks a 
bit better) there are not that many really active contributors in KDevelop. We 
have several people who care about the project, which is great, but most of 
them currently do not have the time to actively work on it.
To improve this situation, we should somehow aim to improve the "amount-of-
stuff-to-maintain" to "people-maintaining-stuff" ratio.

One way forward which came up during the discussions, which we can or can not 
try to follow, goes like this:

 - Identify things in KDevelop which significantly increase the complexity of 
the application, and do not really provide that much value to the user 
(because their functionality is limited, buggy, or easily provided by other 
means). A first list of these things could go like this:
    * Working Sets
    * Debug/Review areas, i.e. the whole Areas concept
    * showing arbitrary document types inline (instead of only text documents)
    * unified version control interfaces for all VCS, instead of just 
implementing each on its own
    * arbitrary split views instead of just split left/right
 
 - Consider removing or very pragmatically simplifying the implementations of 
these concepts. Make a list of workflows we want to support nicely in 
KDevelop, and try to identify buggy features that are not required by these.

 - Once there is a rough plan, organize a sprint (maybe in Berlin, to make it 
easy for the people with little time to attend?) which concentrates only on 
simplifying stuff.

The hope would be that this, in addition to increasing the perceived polish of 
KDevelop by removing things that behave flakily, makes it much easier for new 
contributors to find their way around the codebase, so they eventually feel 
incentivated to try fixing stuff themselves. Thus, we decrease the amount of 
stuff to maintain, and make it easier to find new contributors simultaneously. 
In theory.

There was also the suggestion of doing a bit broader survey to identify the 
things people actually use KDevelop for, but I first wanted to hear some 
feedback from the list (maybe nobody wants anything like this to happen and 
everyone just wants to continue like we did the last years?) before attempting 
to organize something like that.

All the best and sorry for the long mail,
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180816/1e2e6619/attachment.sig>