Akademy BoF wrapup, or: KDevelop 4 is about ten years old, how is it going to shine in the next ten years?
mail at svenbrauch.de
Thu Aug 16 21:02:26 BST 2018
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?
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
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.
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,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel