on feature requests

So while deprived of Internet access due to various snafus that arose in the midst of my move, an article hit Linux Weekly News about how we as a community of developers are apparently struggling with feature requests. The source of the material was a thread on the kde-devel mailing list where feature additions for KDE 4 was brought up, and in particular features that were in KDE 3 that are not in KDE 4.

Since it was deemed interesting enough a topic to appear in an article on LWN, I figured I should add some detail and context to the outline that article provided. It is an interesting topic.

In general there are four kinds of feature requests I come across:

• The reasonable and well explained which many people would benefit from (where "many" is contextual to the application and feature in question)


• The reasonable and well explained, but low priority due to other work ongoing and/or size of audience that would benefit


• The reasonable, but unlikely due to design choices in the software


• The unreasonable


• The incomprehensible, usually because the request is made in haste and/or with little care/li>
  

The challenge starts with the ones that are unreasonable, incomprehensible or unlikely. For a significant percentage of those reports, if they are closed along with an explanation, the reporters get frustrated (understandable), annoyed (understandable, if not really called for) and too often start harassing the developers on the report (not cool). I'd understand it if the developers in question dismissed any and all reports and didn't give some reason for the closure. This is almost never the case, however!

The challenge extends with the low priority feature requests. To the requester, the feature is important. Otherwise they would not have reported it, right? So when it doesn't get implemented right away, the reporter sometimes gets impatient and starts bugging developers.

What all of this leads to is developers not closing feature requests that ought to be closed and even staying away from engaging often or at all with feature request reports. They will implement what they can when they can and then close the reports then with little feedback.

The real casualties are the valid and high priority feature requests. They often languish in a swamp of requests that won't go anywhere, making them hard to find and track and often even just ignored until the developer gets around to that feature.

Adding insult to injury is the choice of the word "wishlist" in bugzilla to refer to a feature request. This gives some reporters the wrong impression that these are not reports with much impact, and unfortunately the current situation just lends to reinforcing that impression.

Nobody is winning in this scenario, user or developer. Now, some KDE project do a great job of dealing with feature requests. In my case, it's been the smaller applications that I've worked on. Their feature request rate tends to be limited, and that makes all the difference in the world. This really seems to be an issue of scale.

It is also, in my opinion, an issue of it being a strictly user-to-developer oriented communication: the user "requests" and the developer "accepts, denies or ignores". It's not very collaborative in structure: it doesn't lend itself to include other users, bugzilla isn't great for holding discussions and the user has little mechanism for input other than to report and then hope it goes well (and kvetch when it doesn't).

Currently it's the worst behaved that get visibility and good ideas have little chance of being fleshed out further or found by prospective users and would-be implementers. This all needs to be turned on its head.

(As a side note, I'm constantly struck by the feeling that Bugzilla is designed with in-house development in mind and is really not suited much at all to open, collaborative approaches.)

Tangentially, I believe that those who decide to get involved by interacting directly with us as developers form a special kind of contributor: those people shape our community's feel, they provide valuable testing and feedback .. but it is a form of contribution and interaction as a member of our creative commons. As such, there are similar responsibilities to other contributors. As software developers (or translators, artists, documenters, etc) we are expected to behave well and when we don't, well, we get rewarded with public lashings. If your project is high profile enough, those lashing happen on the community news sites. There's little one can do about it as it's not a fair trial by jury or even paired with mechanisms of feedback, negotiation and consensus. We are also held to standards by our fellow contributors as well as our own expectations and consciences. This is to say, contributors have very real consequences to their actions. Unfortunately, for people who interact as involved users there is little if any responsibility tied to their actions. This is unfortunate and ultimately a negative thing as it results in a few people running around behaving badly and ruining it for others. Something to think about.

Back to feature requests, however, it seems we really do need something that allows more user-user interaction, provides a way to incubate ideas to maturity and allows developers a way to interact in a productive manner rather than simply judge. Being able to tie in reputation would be a bonus.

OpenSuse's FATE (which I've heard there is a KDE client for somewhere?) and KDE's own Brainstorm are two examples of tools that are starting to develop and which are probably much better suited to dealing with feature requests in a collaborative, positive and enjoyable fashion.

I want to see the good ideas float to the top and get the attention they deserve (e.g. implementations) and the good ideas that need to be prioritized for later still get the attention they deserve so nobody feels neglected.

It would be easy to just ignore the whole situation, of course. We manage along OK as it is; but it could be much better. Which is why I cared enough to say anything in the first place. :)

(I'm writing this from the boarding gate in YVR airport; I was the first to make it through the gauntlet of check-in, customs and security. Huzzah! :)