[maemo-community] Bugzilla or else to handle feature requests?

[From: Dave Neary]

Hi,

Quim Gil wrote:
> http://wiki.maemo.org/Task:Brainstorming_new_features is a task still in
> the maemo.org backlog but there is one question that would have a bigger
> impact depending on the answer:
> 
> In the long run, where should feature requests be handled?
> 
> a) http://bugs.maemo.org as nowadays, making it more friendly to end users.
> 
> b) A specialized tool like http://brainstorm.ubuntu.com/
> 
> c) Else

The problems with Bugzilla are that it's not particularly adapted to a
feature request type workflow, which usually includes the following things:

 - Feature request comes in
 - Perhaps during a feature sprint/release cycle planning session,
requests get looked at, discussed and prioritised
 - You might want to get the feature broken up into smaller tasks to
make estimating it easier - something akin to a spec document
 - In most places, you'll do some kind of risk analysis of it and
evaluate how much the feature might cost
 - When the feature gets done, it goes into testing, and finally gets
released

In my experience, using bugzilla to gather feature requests results in
lots of feature requests gathering dust for a long time.

In Bugzilla, this workflow looks like:

 - Bug opened (if the person creating the report thinks to do this in a
bug database)
 - Discussion of the feature happens in the bug report
(advantages/disadvantages of the feature
 - Specification happens in the bug report
 - Tracking testing happens in the bug report
 - Finally, when the bug is "fixed" and the new feature available, the
bug report is closed

So what's wrong?

There are 3 distinct different discussions here:
 - Is the feature worth doing?
 - How should we do it?
 - Is it done right?

Putting them together doesn't seem like the right thing to do.

You will occasionally get people adding "I don't think we should have
this feature" comments after it's been discussed and implemented. Or
revisiting the specification when the feature's finished & in testing.
These things shouldn't be impossible, of course, but there should be a
clear separation between the different types of conversation, I think.

In fact, "how should we do it?" should really be a short document that
converges quickly, rather than an ongoing discussion, and document
handling in Bugzilla sucks (wikis are better).

A heavy feature might result in lots of bugs at the testing stage - in
Bugzilla this gets handled by creating new bugs, all of which are
dependencies of the feature request bug (so the feature request gets
marked done only when the bugs with it are corrected), but this is
sub-optimal.

I have seen one place where the feature request got closed when it was
implemented and testing was started, and a new component was created for
the feature, and bugs in the feature are assigned to that component. But
that's horrible and no-one should ever have to use a bugzilla where that
gets done.

In Launchpad, you have the whole cycle defined to split out these
conversations - the brainstorming site is for feature requests, when
accepted they need to get a specification document, they're tracked in
the release management section, before finally getting released.

The core question, then, for me is:

Is Bugzilla completely inappropriate, or not?

Cheers,
Dave.

-- 
maemo.org docsmaster
Email: dneary at maemo.org
Jabber: bolsh at jabber.org