[RFC] Track Feature requests in Bundle Buggy?

[Wouter van Heyst]

On Tue, May 01, 2007 at 02:26:32PM -0400, Aaron Bentley wrote:
> Martin Pool wrote:
> > On 4/28/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > 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.
> 
> I would have no problem with RFEs in Launchpad if they were handled
> separately from bugs.  If you look at issue trackers like Trac, they
> distinguish between "defect", "enhancement" and "task".
> 
> > We can distinguish feature requests from bugs by setting the
> > importance=wishlist; we should make sure to do this for new things.
> 
> This isn't adequate.  The difference between bugs and features isn't a
> difference in importance-- it's a difference in kind.

Years of Debian bts have trained me, bugs and features are the same kind
of thing to me. But I'm aware not everyone thinks like that, I can work
with a more granular view.

> 
> > But I'm not sure they need to be starkly distinguished
> 
> I want them to be starkly distinguished.  When I'm browsing bugs, I'm
> not interested in features.

Better filtering the amount of bugs we have is certainly something I'd
welcome, I'm not usually annoyed by features, but if it helps make the
corpus more manageable, sure.

...

> > On the other hand Launchpad has the "blueprints" classification which
> > is aimed more at describing new work.
> 
> I'm not sure whether that's appropriate.  I think people would not
> expect to use "blueprints" unless they were actually designing the
> feature in detail.

Agreed, filing blueprints without (the intention of writing) a spec that
helps in implementing the feature hog real estate. Likewise I think
there is a certain complexity threshold.

> >> 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.

1 and 4 are improvements I care about. Having the gmane thread might
just make 7 bearable.

> >> Does this seem like a good approach?

Yes, and certainly if it makes your life easier, +1

Wouter van Heyst