Re: Random TODO list

[Olav Vitters <olav bkor dhs org>]

On Wed, Aug 11, 2004 at 11:25:46AM -0600, Elijah P Newren wrote:
> I've built up this *long* list of TODO items for the bugsquad.  I
> figured there was no point letting it bitrot on my computer (especially
> when a sysadmin can nuke my local bugzilla installation and lose part of
> the info--grrr.), I might as well email it to the list so that it can
> bitrot there.  :-)

You've also listed some b.g.o items, so let me add some more...

Triage mode
I'd like an b.g.o 'triage mode' which would activate things like:
 * Highlighting stack traces
   Using some regexps to highlight the functions in a different color
   (like yellow) and the 'signal handler called' in another color (like
   red).
   I've had such a hack in privoxy (until I deleted my config), it was
   very handy.
 * Stock responses next to 'Additional Comments' textbox. Something very
   easy (simple javascript links maybe) to add the comment and possibly
   also set the resolution (should not do a Commit).
   It should be very fast (faster than copy&paste using mouse selection).
 * Two additional small text box to allow fast searching within product
   and component. Search should be for all bugs (open and resolved).

Workable X-Bugzilla-Reason
See patch in bug 139173 (adds Watcher as reason). Seems to survive my
tests, but that doesn't say much.

Moving between products should always allow choosing a different
component
Currently if both products have a general product the 'choose component'
page isn't shown.

> TODO webpage
Agreed.

> MAINTAINER section
> I already added a maintainer section on front page of
> bugzilla.gnome.org.  But is there anything else that should go there?

I would like a 'What a maintainer should know/do/is expected of',
listing all Bugzilla tasks maintainers should do/check. This means
review patches, but also things like making the WONTFIX decision.
Another thing is listing that communication with bugsquad is appreciated
(items for product specific guidelines and other requests).


> OBSOLETEVERSION resolution
Ok, but the obsolete versions should be added to the product specific
guidelines.

> Product Specific Guidelines
> I let the ball drop here.  Richie Wentzel and Chris Davidson did some
> great work on gathering guidelines specific to various products in
> bugzilla.  Unfortunately, I let the ball drop, didn't follow up, and
> didn't make sure their work appeared in the bugsquad pages.  That needs
> to be fixed, and I believe their work could be continued.

Would be really great. Currently you really have to follow a product for
a while before you can effectively triage bugs.

> NEEDINFO hard to work with
Automatically reopen is great, don't care about listing more options.

> Reassigning inherently error-prone
> Most people try to reassign by simply selecting a different product
> without selecting "reassign to owner of selected component".  I have
> also made that mistake multiple times.  We should have bugzilla ask for
> confirmation if the person wants to keep the same assignee but reassign
> the product/component elsewhere.

Maybe automatically select that option if you change the product using
javascript?

> Two versions of bugs-filed-today
> The list of bugs filed today on bugzilla.gnome.org (bottom right corner)
> doesn't match bugs filed today (just below "reports specific to the 2.x
> effort).  Does this matter?  (side note: "reports specific to the Gnome
> 2.x effort" is an obsolete and misleading title; we're not concerned
> with Gnome 1.x anymore)

For me its main purpose is giving bugs to triage. As long as it does
that I don't care.

> Improvements to triage guide
> (1) Guide on reading stack traces, (2) encourage people to add
> themselves to cc list whenever triaging, (3) add example IRC
> conversations about triaging and mailing list posts about triaging for
> the timid who want to see how others ask questions before they do so
> themselves, (4) add information about debuginfo packages to the getting-
> traces.cgi guidelines, (5) Update the examples (the image header isn't
> included, and the old bugzilla page format is shown), (6) more
> predefined searches (see below)

Agree with all. Point 4 is very interesting. I was thinking about making
a RFE (haven't searched for dupes ;) ) in bug-buddy that it
automatically installs (after asking) or requests the debug packages.

(7) add more triage hints (stuff triagers should do/check/know but
currently isn't documented)

> More specialized searches/reports
> Many possibilities.  Some that I've though of: (1)
> unknown bugzilla gnome org as assignee (especially for the "general"
> product, no one tends to handle these giving reporters the feeling they

I do not like unknown bugzilla gnome org as assignee. It prevents me
from watching that product. Why not changing it to a -maint alias? I've
requested this from bugmaster@, but got the answer that a product
requires a clearly defined maintainer (could be that I misunderstood the
answer). I can understand the reason (there is no maintainer), but do
not like it.

> are being ignored), (2) bugs where assignee doesn't match the default
> one but does match an assignee of a previous product the bug was filed
> under (wouldn't be needed if we did the confirm upon reassign thing),
> (3) bugs for which no one has commented on besides the original
> reporter, (4) most frequently *and recently* reported bugs (who cares if
> 59500 was duped a lot if we don't get reports anymore....), (5) bugs
> that tend to be misfiled (e.g. bugs against gnome-desktop (usually are
> nautilus bugs), bugs against general (often come from users who don't
> know the correct product name), bugs against acme (often come from lazy

Maybe also have an 'i-dont-know' product, so users can file bugs there
instead of having misfiled bugs everywhere (acme, general, bug-buddy,
...). And add bug-buddy support for it.

> users who don't want to look through the list), (6) a report that
> specifies for each product/component the percentage of patches from the
> last x months that have not been reviewed (this could serve as an aid to
> the release team in recognizing modules being undermaintained.)

[..]
> Bug Guru page
> Calendar

Sounds good.

> Easy-to-triage report
Maybe also add a 'easy-to-triage' keyword. It is more work on the
short-term, but saves a lot of work if it creates a few new triagers.

[..]
> You just skipped to the end of this email instead of reading everything
> I wrote above, didn't you?  Not that I blame you, but... you're so
> lazy.  :-)

Yes, but I always read bottom, top, somewhere in the middle, top again,
etc.

-- 
Regards,
Olav