Re: Bugzilla read to go live?

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp redhat com> writes:

> Hi,
> 
> Looks good. I played with it and came up with lots of nitpicks
> though. ;-)
> 
> I think the text on bugzilla.gnome.org is confusing:
> 
>  This is Bugzilla: the Mozilla bug system. For more information about
>  what Bugzilla is and what it can do, see mozilla.org's bug pages.
> <bugzilla.gnome.org/bugs.jpg> This is where we put in lots of nifty
>  words explaining all about bugzilla. 
> 
> How about "This is the GNOME bug tracker. Choose one of the following
> tasks:" or the like. Then link to mozilla.org somewhere on the bottom
> of the page in fine print. 

OK, I changed it to something like this - no fine print though - there
was enough whitespace already without having to impair legibility.
 
> The same confusing text seems to be on other pages too...

I think you were seeing it in the footer. I've removed it from
there.

> On the bug entry page, "If you think it got it wrong, please tell
> Martin Baulig what it should have been" should probably give Martin's
> email address, or better some bugzilla maintainer alias.

In that place I changed it to say to file a bug report against
the bugzilla.gnome.org product. I also changed the maintainer
email to bugmaster  gnome org and set up that alias to
point to Martin and myself.
 
> The two Access dropdowns seem to provide combinations that don't make
> sense. e.g. if I say "only bugzilla maintainers" and "only gnome
> hackers" do I get the union or the intersection of those groups?

I thikk the wording correctly expresses the fact that it is the
intersection - if you select both, it will only be visible to people
who are both bugzilla maintainers and gnome hackers. How would
you improve it?
 
> I added a bug: http://bugzilla.gnome.org/show_bug.cgi?id=40011 If I
> try to change status to Assigned then there's an internal server
> error.

Permission problem. Fixed. (If you are working on bugzilla, please
use the cvsup script in the bugzilla user's home directory instead
of updating by hand.)
 
> http://bugzilla.gnome.org/bug_status.html documents an UNCONFIRMED state that 
> doesn't seem to be used (my bug went in as NEW, maybe because I
> assigned it to myself and have canconfirm permissions?).

confirmation is tied up with voting for bugs in a weird way -
if the product has a setting for 'votestoconfirm' than bugs
are entered by default in the UNCONFIRMED state, if not
they are entered in the NEW state.

A bug can be confirmed either because of::

 - voting
 
 - Or because someone with canconfirm permissions sets the status
   as NEW either when submitting the bug or later.

So, if you set a product to have some number of votes to confirm,
you'd reveal all the bugs I've introduced in the confirmation mechanism.

 - Should we remove the UNCONFIRMED state?
 - Should we enable it with only manual confirmation?
 - Should we expose the voting mechanism? (ugh)
 
> The help-with-field links on bug pages, such as
> http://bugzilla.gnome.org/show_bug.cgi?id=40011, go to bug_status.cgi
> instead of bug_status.html. e.g. click on Resolution: on the bug page
> and you get a 404.

Red Hat bug tracker accidental carryover. Fixed.

Regards,
                                        Owen

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers