On Fri, Sep 10, 2004 at 08:30:00AM -0500, Steve Greenland wrote:
> If there's a specific item(s) in that article you're thinking of, you
> should point it out, rather than forcing everyone to try to read your
> mind.
Sorry, Steve, I didn't intend to annoy you so much.
IMHO, we miss could get some inspiration from this:
1. FogBUGZ lets you create inquiries as well as bugs, because in the
real world, touchy programmers get insulted when they are accused of
having a "bug," resulting in skittish testers who are afraid to
enter reports.
2. FogBUGZ tracks bugs and features, so you can prioritize them on the
same scale, fixing important bugs and implementing important
features before fixing inconsequential bugs or implementing silly
features. You can even set the priority on customer email and other
inquiries so FogBUGZ becomes a complete task manager for every
member of the development team.
3. FogBUGZ brings your customers into the loop. You can create a
project for "customer wish lists" and let customers email their
suggestions into it. Your software designers can sort through these
requests, and promote any inquiry into a feature
And since I feel the "we can do it with wishlist bugs" axe about to fall
down on me, I'll point out what ideas I think we could get from there:
- We have no way to create "inquires"[1]: if I can't understand how to
do something in an application, it would be nice to file an inquiry:
maybe the feature is not there (so it would become a wishlist bug),
maybe it's not documented (so it would become a wishlist bug), maybe
it's there and is documented (so I would probe the user a bit more to
see if we have a usability problem or a PEBKAC). Inquiries could be
filed, why not, automatically Cc-ed to debian-user, so that the
bigger user community can help address them, and the package
maintainer has a track of what's going on with his/her package.
- Tracking "features" differently than bugs (wishlist bugs are still
bugs)[2], with the possibility of sorting wishlist items and random
feedback into "feature" trackers[3], to organize and aggregate the
various feedback into proper work plans, instead of keeping huge,
unmanageable lists of wishlist bugs sitting around to clutter the bug
report.
Along this line of thinking, bug grouping would probably be an useful
feature for major projects with lots of bugs.
Let's have, for example, a look at the aptitude, ifupdown, apt or
bugs.debian.org bug pages:
aptitude: 91 normal, 35 minor, 77 wishlist
ifupdown: 16 normal, 2 minor, 56 wishlist
apt: 70 normal, 38 minor, 268 wishlist
bugs.d.o: 27 normal, 13 minor, 111 wishlist
we see that those huge wish lists could use some more structure. I
can't speak for the maintainers of those packages, but I myself have
problems when reporting a bug there, just to browse the whole list to
find out if a similar bug has already been reported or not.
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
Attachment:
signature.asc
Description: Digital signature