Changing the Feature Request Workflow for KWin

As a reader of my blog you should know that I am rather unhappy with the situation of our bug tracker. Last week there was an incident with our bug tracker which should not have happened: the upgrade of our bugzilla installation broke the automatic submission of crash reports through DrKonqui. Given the stats for KWin of last year, I have to admit that I was not unhappy about it. My first expectation was that for at least a month we would not get any new crash reports and probably none for outdated versions ever again. Now our sysadmins and DrKonqui developers rock and have already fixed the issue 🙂

Nevertheless I took this incident as a motivating factor to start a cleanup of our bug tracker. Not getting new bugs and having to set them to duplicate frees some resources to go through the existing reports. At the time of this writing KWin went down 48 bugs and 160 feature requests over the last seven days.

During this work I concentrated on cleaning up the feature request. In the past the assumption was that each feature request is valid. Of course users may wish new features. Nothing wrong about that. Unfortunately this results in more than 350 feature requests and the oldest ones being reported against KDE 2.0. Well if a feature request has been reported more than ten years ago and nobody has thought about implementing it, we come to the point where we should consider facing the reality and stating that we won’t implement it. From the request I went through there were things which would have required a rewrite of KWin, many features which had been implemented or implemented in a slightly different way, just really bad ideas and many wishes for additions where we just don’t have the time for.

For the future I want to see new workflows established concerning feature request for KWin. First of all feature requests should not be entered in the bug tracker but on the brainstorm section of our forums. This allows other users to vote on the idea giving us developers a better understanding whether the feature is really wanted or just fixing a corner case of one user.

As a result feature requests in the bug tracker should only be there if we plan to implement them. For this I started to introduce “target milestones” for version 4.9 and 4.10 and started to flag the requests I consider as useful with these milestones. Feature requests which I consider as useful but cannot be implemented right now were made dependent on other feature requests which are already targeted for a specific release.

This will also change my own workflow for developing KWin. All the features I work on will end up as tasks in the bug tracker. Currently the ideas are either only in my head or as sticky notes on my whiteboard. Both is not a good solution for doing development planning and tracking dependencies between the tasks or verifying that all tasks get implemented before the feature freeze. But from my own experience I know that bugzilla is very capable of doing exactly that work.

For establishing such a workflow for myself it is of course necessary to first clean up the feature request. But in the end this gives everybody advantages. I have a better managed todo list which is shared with everyone. Given the target milestones all users and possible developers can see what (list is not yet complete) will end up in the release or where help is required.

Changing my own workflow is also quite important as I can manage my own available development time much better. Since November I have reduced my day job to have more time for KDE and started to do consulting work around KDE on the weekdays I have not been at my day job. Since recently I also belong to the group of developers working for the Netrunner OS distribution and since March the BlueSystems, the company behind Netrunner OS, is sponsoring two days a week for KDE development. Thanks a lot for the trust in the KDE community.

Now to something completely different: I not only worked hours through the bugtracker but have also been one day on a development sprint for Plasma Active. We had very good discussions about various aspects of the development of our workspaces 🙂 I used the short train journey to Darmstadt to rebase my JavaScript bindings for KWin Effects on current master with the result that yesterday I merged them into master. It still needs some final adjustments and documentation, but overall I’m quite happy about it. I remember that I talked about the ideas for the first time last year at the sprint before Plasma Active was announced and I think it is just a nice coincidence that I added the finishing touch to this work one year later on the way to and fro the Plasma Active sprint.

7 Replies to “Changing the Feature Request Workflow for KWin”

  1. please excuse this offtopic question…. from your point of view: what are the main differences between kubuntu, netrunner and linux mint?

    i just learned about netrunner and it looks like i’m going into the same direction with my very own remastered kubuntu system (live usb) for my students.. looks like i’ll switch to netrunner for the next “release” of my version and save a lot of time installing and configuring things

    1. Hello xapient,

      since one can say I am obviously biased, I’ll try to answer as neutral as possible:
      Kubuntu is the base for both MintKDE and Netrunner and is shipping (almost?) pure KDE with default configuration (no gnome programs on fresh install if I recall correctly). It’s a great way to start from if you want either pure KDE or explore how to tweak KDE your own way.
      MintKDE comes already with additional tweaks and codecs (much like Mint used to do with Ubuntu before the Unity/Cinnamon/Gnome3 split).
      Netrunner imo makes a bit more “dramatic” changes away from KDE default oxygen look with tweaking KDE to on surface make it resemble a well known non-linux based OS (like classical menu, window decoration) and somewhat give a “familiar feeling” for those who come to linux first time. Netrunner also add things even more stuff on top of KDE like Gnome+Wine for a mixed environment and firefox addons, etc.
      So since all three (or rather any) KDE distros can be relatively easy tweaked and enhanced to your liking, it’s a matter of taste and personal preferences which distro you choose to start from as base.

  2. (Disclaimer: no sarcasm intended, only apology.)

    I must confess; I have been using the bugtracker for such feature requests. Due to naïvete on my part I wasn’t aware I should instead have favored the forums over the bugtracker’s wishlist category. I[1] have[2] posted[3] several[4] ideas[5] of changes or additions of varying complexity that I all thought would be junior job-level to implement, but in retrospect none of them have really been welcomed. It all makes sense if I was actually posting them in the wrong place.

    Apologies for the added tracker noise.

    As you commented in one such report[6], hopefully the new scripting API will offload script development from the maintainers.
    >With the next version 4.9 KWin will provide the possibility to write simple
    >animation effects in JavaScript. This allows everyone to write and distribute
    >small effects. For future versions even more advanced bindings are planned.
    >Furthermore there is the C++ API which gives full control. We are happy to
    >evaluate new effects provided as source code for inclusion.

    Dare we hope to see a Get Hot New Stuff feature for KWin, or would that be too complicated and/or prone to crashing?


  3. This sounds very good. Clearly, wishes that won’t go anywhere will not be useful to anyone. Also, development milestones visible to all, including dependencies, etc. sounds like the way to go. I think this should be done by all of KDE.

Comments are closed.