[Cabal] Bug Reporting

[Luke Schierer]

On Sun, Nov 05, 2006 at 07:34:47PM -0600, Richard Laager wrote:
> A recent experience of mine with a particularly obnoxious user had the
> beneficial side effect of giving me the following ideas, not all of
> which are new. I thought I'd mention them here so we can consider them
> for Trac:
> 
> a) Users should not be able to modify bug attributes. They exist not for
> the user anyway, but for us. Having them editable by the user makes them
> think it's something they *should* edit. This is worth considering when
> we switch to a new bug tracking system. I think we can make these
> statuses more useful to the user; see my suggestions below as (c) and
> (d).

I absolutely agree.

> 
> b) The SF bug submission process is horrible. We only have the ability
> to put a small note for users to search existing bug reports. I think we
> should look more towards one like that of GNOME. They have a really nice
> multi-step wizard. It's great for newbies, and as an experienced bug
> submitter, I'm okay with it. My only beef with it is that there's no way
> to get a full list of components; you have to know the category first,
> which isn't always intuitive. This wouldn't matter for Gaim, since we
> don't have that many components and the users needn't deal with that
> anyway. Again, something to keep in mind for a new system.

One of the flaws of bugzilla is that it forces you to guess for all
sorts of settings.  Don't know what component your bug is in?  Ahwell,
you can't skip that.  Similarly for other settings.  For gnome, I can
understand forcing the wizard view.  They have tons of projects and tons
of developers who don't know more than a tiny portion of the code.

I do not think our users should be expected to guess if theirs is a bug
in the core or UI.  And yet, classifying our bugs that way is useful for
us.  Really we just want to give them a fill out form that asks
questions like what version they have, what sort of system they are on,
what happened, so on.  I think a wizard is overkill.

> 
> c) It might be helpful to have some sort of note show up automatically
> when something is marked a duplicate. This would say something like,
> "This bug is a duplicate of [link to other bug number]. All further
> comments should occur there." Then, nobody should be able to comment on
> the bug again until it's either re-opened, or the resolution is changed.
> I don't think there's a systemic problem with people "not getting it"
> that you should take your comments to the other bug, but this would be
> helpful in a few cases, such as this one.

I agree.  How does trac handle duplicates?  Can it merge reports?
create such a link semi-automatically?

> 
> d) We could do similar things as listed in (c) for other cases: Out of
> Date ("Please try your bug with the latest version of Gaim and comment
> here if it's still not fixed."), Fixed ("This bug has been marked fixed.
> The fix will appear in the next release. If the bug is not fixed for you
> in the next release, please comment here."), and possibly others.
> 

it would be nice, but it would, based on the fact that canned messages
are a hard problem, probably be hard to implement.

> e) The bug reporting wizard needs to start and end with some notice to
> the effect of: "The Gaim project appreciates your bug report. It will be
> triaged and evaluated by developers as their time allows. If they have
> further questions, they will be posted to the bug report for you to see.
> You will get an e-mail for changes to the bug report."
> 

thanking users for feedback is good.  Telling them where to find their
own bug report is also needed.

> 
> I have no idea how much of this Trac already does. I haven't had time to
> play with it much yet. I just signed up for it. BTW, do I need to do
> anything to get magical powers? I'm "rlaager".
> 

Yes, you needed to be added to the developer group and granted
TRAC_ADMIN permissions.  Someone beat me to both.

luke

> Speaking of which, I really like the notes in bug comments on GNOME
> Bugzilla. Effectively, they mark "(developer)" and "(submitter)". I know
> there are times when I've gotten confused by someone other than the
> submitter talking about something. I don't know if we want to mention
> "(developer)" or not. It's a useful thing, but it does promote classes
> of users. Anyway, not sure if Trac does this, but it's a thought.
> 
> Richard
> 
> 



> _______________________________________________
> Cabal mailing list
> Cabal at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/cabal