[RFC] Track Feature requests in Bundle Buggy?

[Martin Pool]

On 4/28/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Some people put feature requests in the bug tracker.  This has the
> advantage that it prevents requests from being lost.  But it also has
> disadvantages:
>
> - - Launchpad shows bugs and feature requests all mixed together
> - - Most feature requests are improved by community discussion, but
> posting a feature request to Launchpad doesn't start discussion on the
> mailing list
> - - It is rude: a user posting a feature request as a bug is asserting
> that Bazaar is broken because it doesn't meet their needs, and that the
> only way to fix Bazaar is to implement the feature they ask for.

I agree about the first two but it doesn't seem rude to me.  (Although
if it seems rude to you, I guess in a sense it is rude.)

A bug tracker has two roles: a point of contact for users, and a place
for developers to remember and prioritize things to do later.  The
default case for bugs is that most things flow straight through from
one to the other but not all: duplicates, user error or confusion,
bugs in other systems, etc.  And some of them need discussion in
between as to how to fix them.  If we say "not a bug" then I don't see
the user as rude for reporting it in good faith and I hope they're not
offended if we explain our decision.

Now for features the gap is a bit bigger: many things are going to
need a lot of rework or not be generally useful, or not be a priority
to fix.  And that discussion may be better off on the list, and
probably more often than not ends up with it being declined/rejected.
But I don't think people who file RFEs (requests-for-enhancement) as
bugs rather than on the list are any more rude or insistent that it be
done, in my experience.

We can distinguish feature requests from bugs by setting the
importance=wishlist; we should make sure to do this for new things.
But I'm not sure they need to be starkly distinguished, it's possible
some features might be more important than some bugs.

On the other hand Launchpad has the "blueprints" classification which
is aimed more at describing new work.

> Since Bundle Buggy already tracks requests made to the mailing list, it
> seems like it wouldn't be too hard to adjust it to track feature
> requests as well.
>
> This would involve:
> 1. adding a new view for feature requests
> 2. teaching it to treat messages with [FEATURE] in their subject as
> feature requests
> 3. providing a web interface for adding feature requests, so that
> non-subscribers have a convenient way to make feature requests.
> 4. data model updates.
>
> Compared to launchpad, this would
> 1. Make feature requests always visible on the ML
> 2. Distinguish feature requests from bugs
> 3. Provide a link to the GMANE archive of feature discussion
> 4. Allow voting on features (not sure if this is a good thing)
> 5. Not provide a way of setting importance
> 6. Not provide a way of adding attachments
> 7. Not provide a convenient way of updating the text of a feature
> request -- you'd need to make a new one that superseded the old one.
>
> 4-7 are things that we could fix if we wanted to.
>
> Does this seem like a good approach?

Well, I do like BB... I guess I'd give it a try if you set it up, but
I'm not so clear on the benefit.  Linking to the discussion is good,
but for me not sufficiently compelling to have features stored in a
separate place.  I'm skeptical about voting on features.

For now I'd suggest just forwarding feature requests to the list, and
then putting them into launchpad when we agree we want to do it...

-- 
Martin