Fate vs Bugzilla for feature tracking

[Matt Rogers]

On Thursday 22 January 2009 21:37:01 Aaron J. Seigo wrote:
> On Wednesday 21 January 2009, Matt Rogers wrote:
> > I have yet to see anything concrete from you (or anybody else except
> > lemma) regarding things that would make Bugzilla easier for them or their
> > group
>
> i've actually shared a few things in the past with you, but i know how easy
> it is to lose things on irc and this is certainly a better forum. so,
> noting that i'm a believer in process and think that the projects that have
> some internal process for coordination tend to do better, here goes my
> brain dump:
>

That's true, you have, but this list is much better. Thanks!

> for me "must haves for true usefulness" are:
>
> * proper comment threading
>
> * ability to easily mix things like screenshots right into the comments
> areas; very important for brainstorming
>
> * ability to delete comments and close reports permanently
>
> * ability to categorize accounts: unknown user, user with demonstrated
> track record, commiter, project lead, downstream, etc.
>
> * ability to rank the importance of a report (not vote on it! i don't care
> if you put 20 votes into a shared pool, i want to know if it's a 1 or a 10
> for *you*), and have those rankings segregated / weighted by account
> categorization
>
> * ability to view lists of reports based on user account; this would allow
> us to use bugs.kde.org as a dev communication tool for things like patches.
> right now, it's completely unuseful for that because all bugs go into one
> place and so we get a mess of user, downstream and contributor reports.
>
> * ability to have developer discussion of a report in a separate thread
> from user input. it's madenning to not be able to have peer discussions
> without being interupted by random joe user who stops by to share his
> brilliance.
>
>
>
>
> the "probably already doable but currently clumsy":
>
> * ability to mark, as a project committer only!, a feature for acceptance
> and have that feed into a feature plan report. from that report, i should
> be able to defer features to the next release and otherwise do simple
> feature plan managemet
>
> * ability to mark, as a distro or other blessed downstream entity, items as
> must haves along with their personal "useful by" date (for a distro that
> would probably be the next version release date); i should then be able to
> view these as separate reports from everything else.
>
>
>
> the "would be awesome, but not critical":
>
> * more structured input form for reports, and different ones for features
> vs defects. i want use cases for features, and reproduction steps for bugs,
> e.g.
>
> * ability to comment patches ala review board
>
> * rss feeds; right now we use mailing lists and they are ok-ish but clumsy
>
> * speed: both in response times but also in the UI workflow; for me as a
> developer, a decently designed rich client would be infinitely better than
> a web browser for this
>
> * ability to annotate with amount of expected work effort for an item
> (skill level and time?) to aid in selection of items for others (e.g. new
> devs coming in, sort of like the JJ: thing) but also to help project leads
> plan a release out without being unrealistic ;)

Thanks again for this list. This gives me the best idea yet as to what's 
needed to make our bugzilla work for us.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090123/9ad9e03c/attachment.sig>