[RFC] Track Feature requests in Bundle Buggy?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

Sometimes, especially around RC time, I go to fix a bug or two.  I want
to list bugs and see only bugs.

> it's possible some features might be more important than some bugs.

This is why I think there should be a difference in kind, not in
importance, between bugs and features.

AIUI, wishlist as a classification should be reserved for those bugs
which are so minor that they're hardly worth fixing.

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

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

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

I don't know how to respond to that.  I just listed the benefits and
disadvantages above.

The benefits are
1. Every feature request starts a mailing list thread
2. Feature requests are distinguished from bugs
3. Every feature request is linked to its mailing list thread

>  Linking to the discussion is good,
> but for me not sufficiently compelling to have features stored in a
> separate place.

Features are currently stored in the bug list, which IMHO is the wrong
place.  This gets them into a "pending feature" list, which is a better
place for them.  I very much want to have features stored in a separate
place, whether that place is on Launchpad or BB.

In addition to linking, there's the advantage that they always start an
ML discussion.

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

Robert doesn't want feature requests to be lost, so he is advocating
putting them in the bug tracker before discussion.  I do not want them
in the bug tracker, so I was trying to come up with an alternative that
would satisfy both Robert and me.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN4ZY0F+nu1YWqI0RAu8yAJ9C8VQUcBuHkCUkh5ShdqB7/HmXkwCfQYVd
v78qhzoEX2cADTDFR+Wvb+4=
=Kvil
-----END PGP SIGNATURE-----