[RFC] Track Feature requests in Bundle Buggy?

[Ian Clatworthy]

Aaron Bentley wrote:
> -----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".
>
>   
Exactly. Better still, I like how some issue trackers (e.g. JIRA) 
differentiate between defect, new feature, improvement and task. From 
both a product management perspective and a planning perspective, new 
features need to stand out from improvements to existing features. One 
common planning approach is to map out a roadmap for new features 
landing over the next few releases and assign resources accordingly. 
Defects and improvements are then delivered on a best effort basis as 
remaining resources permit within each release.

>> 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.
>
>   
Agreed. But for now, I think LP is close enough. While not optimal, we 
can work as follows:

* New Features = Blueprints
* Defects = Bugs
* Improvements = Bugs marked as priority 'Wishlist'
* use Milestones much more

So we lose being able to prioritise Improvements, track tasks and 
comment (as easily as we can on bugs) on new features.
>> 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.
>
>   
That's a function of filtering. Again, LP is getting better every 
release while not being as good as I'd like right now. As an excellent 
example of how to do this properly, see 
http://jira.atlassian.com/browse/CONF. One can filter really quickly on 
Release, Priority, Person or Component. Having pulled up a table of data 
by clicking on any of those links, one can sort or filter by issue type 
or any number of other criteria. Trac and other tools are equally 
powerful. Try the "Roadmap" and "Change Log" links though for some 
really nice views on status towards the next milestone and a summary of 
recent releases.

LP does give us a tagging capability though I think Components are still 
needed.
>> 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.
>
>   
I like that explanation. *After* LP gives us a better way of marking 
improvements, we should use it that way.
>> 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?
>>>       
I like BB a lot but I'd rather we didn't extend it in this direction. I 
think that many of us agree that the answer is a better issue tracker, 
not different trackers for different types of issues. In the regard, I 
feel we are best served by working closely with the LP guys to get it 
closer to what we need ASAP.

The multiple tracker route is particularly messy w.r.t. improvements vs 
defects. I say that because the difference is frequently (25% of the 
time?) a matter of perspective. I like to use defect to mean "the 
product is broken". A consequence of this is that usability issues get 
marked as improvements and things that really are busted stand out. A 
large percentage of users though use defect as "the product didn't do 
what I expected". With that interpretation, usability issues are often 
reported as bugs. Having everything in the one tracker makes it much 
easier to simply reclassify the issue type during new issue triage 
(rather than some more complex workflow if multiple trackers are involved).

My 2c,
Ian C.