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.