Mar
23
2010
Feature requests: discuss, implement, or reject/deny?
Author: Jeremy SmythI work in another publicly accessible community, where bug reports and feature requests are happily solicited from the userbase.
We have thousands of open idea requests (the codebase is nearing 20 years old), and close only a sizeable fraction of those opened regularly.
From our perspective, the idea requests are welcome, but not all of them are actionable; some are brilliant, and are implemented immediately because they work well with our vision; some are entirely incompatible and are closed/denied.
The majority fit in between; they’re ideas that would work with a bit of tweaking, or a bit of thought, but aren’t necessarily on the primary development roadmap, so don’t get our attention immediately. Nor do they warrant closing, because they are relevant, merely not timely or important.
Because our developers have their own ideas, their own neverending todo lists, we treat the open idea pile more as inspiration than as a roadmap. There’s very much a feeling of “we’ll get to it when we’ve run out of other things to do”, but this never happens in practice.
I know it’s a cop-out not to choose one or the other, but I think it’s a normal thing to have to choose between two equally bad things in a public forum like this: either responding to most feature requests with a “denied”, and so risk upsetting the folk who love the community enough to contribute with their own ideas; or leave some of them dangling because they’re not immediately and obviously wrong, but to do something worthwhile with them takes more time and effort than the idea deserves right now.
