Fate vs Bugzilla for feature tracking

[Michael Leupold]

On Friday 23 January 2009 04: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:
>
> for me "must haves for true usefulness" are:
>
> * proper comment threading

While this is currently not there it shouldn't be too hard to implement. 
There's a pending wish in bugzilla's bugtracker so I think it might be 
appreciated upstream.

> * ability to easily mix things like screenshots right into the comments
> areas; very important for brainstorming

I agree this is useful (maybe presenting as a thumb to get a quick overview?).

> * ability to delete comments and close reports permanently

Not sure about that. Closing bugs permanently might be useful for stubborn 
users reopening closed bugs but I'm not sure about the "deleting comments" 
part. Ideally we could keep all information but still have only the useful 
part visible.

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

Nice idea. Might be possible.

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

Lists of reports based on user account are already possible. Lists based on 
account categorization of course depends on implementing that feature.

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

Bugzilla provides an "insider" group and private comments. I guess this 
feature might be controversial though. This might be unneccessary if comments 
could be threaded and maybe made invisible using some comment rating system 
(after all there might still be valid input from a non-insider).

> 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

I think we're just not using that feature yet. Bugzilla's target milestone 
feature should be enough to implement it. Predefined feature plan reports are 
indeed nice-to-have.

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

Not sure. After all we're having fixed release dates. Apart from that adding 
extra marks shouldn't be hard.

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

Possible, just needs template modification afaik.

> * ability to comment patches ala review board

That's indeed a hard one and might need substantial modifications to 
Bugzilla's code. Currently only viewing diffs is possible. Especially the per-
line discussions/comments are hard.

> * rss feeds; right now we use mailing lists and they are ok-ish but clumsy

Sorry, I don't understand what you mean/want the rss for.

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

Let's hope the new kbugbuster gets there.

> * 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 ;)

I think that's already builtin.

One additional item I'd like (back):
Replying to comments using email. I think this got lost in the migration to 
3.0. I'm however unsure if we just need to reintegrate it or if our current 
Bugzilla just lacks the support for it.

Regards,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090123/8b4ae522/attachment.sig>