Random TODO list

[Elijah P Newren <newren math utah edu>]

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

If anyone dislikes any of the ideas here, let me know so that we can fix
them up.  Wait a minute...no one will give me feedback with that kind of
request.  Hmmm....  [/me thinks for a minute]  I have lots of ideas
here.  I'll intentionally throw in some that would be a Really Bad Idea
(tm).  Let me know which ones you object to, so we can make the list
more palatable.  No objections -> I feel no regrets in making changes
that put you in a world of hurt.  ;-)


[cue ominous music]
THE LIST:

TODO webpage
Because I have so many ideas below (and others may add to the list),
perhaps a good thing to start with would be to make a TODO webpage
somewhere in the bugsquad pages that list all these things.  Then if
there are any Gung-ho bugsquadders, they can see if they want to tackle
any of the tasks.  If not, I'll get to them when I get to them (which,
considering how long some of these have been on my TODO list, might be a
while.)  It would also be good to link to this page from the gnome-love
wiki because some tasks may be good for contributors new to Gnome.

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

OBSOLETEVERSION resolution
I think it would make sense to s/GNOME1.x/OBSOLETEVERSION/ for
resolutions; For example, gnome 1.x doesn't make sense for modules
outside core gnome, yet they could use an obsolete version resolution.
(In particular, dia gets many bug reports for 0.88.1 which is is
ancient; later versions fixed mounds of bugs and the maintainers report
that most any 0.88.1 bug report is totally useless because of this).
Also, we will eventually want to ignore reports against 2.0.x.  In fact,
nautilus already does ignore most reports against non-recent versions.

GNOME Version/Milestone conditional
It really doesn't make sense to show GNOME Version and Gnome Milestone
in show_bug.cgi for products which aren't part of the D&DP.

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.

NEEDINFO hard to work with
Bugs marked as NEEDINFO only have a few options; typically people have
to reopen them and then go back to the bug and make the change they
really wanted to.  Why not just list more options to start with?  Also,
it might be useful to default to having NEEDINFO bugs be automatically
reopened when a comment is added, with a toggle to enable people to
leave them as needinfo when commenting.

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.

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)

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)

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
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
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
Basically, this would be a page that lists people who have closed
hundreds of bugs and who can often be found on IRC.  This would allow
new people to know who they can turn to with questions (and, of course,
bug gurus could defer to the bugmasters if they are unsure).  Hopefully
these would also be people who would volunteer an hour here and there to
help run Bug days.  It may also be useful to provide "more advanced
queries" for the bug gurus (e.g. old untriaged bugs for which no one has
responded to the reporter)

Calendar
Perhaps not too suprisingly, no one seems to have a free 12-hour block
to run Bug Days.  It would be helpful if we could have an online
calendar where people could sign up for a couple hours saying that
they'll help run Bug Days during that time.  There have been many times
I could have helped out for 2 or 3 hours.  But it doesn't seem worth it
to announce a bug day for such a short time.  If multiple people sign up
for a few hours, though, this could easily solve the we-never-have-bug-
days-anymore problem.  (Perhaps we can even add a policy about trying to
announce bug days whenver we have people signed up to run at least X
hours)  This could also be used to list topics for Bug Days, if there be
any.

Easy-to-triage report
Some new bugsquadders, when picking random bugs to triage, pick multiple
hard to triage reports in a row and get frustrated.  Perhaps it would be
useful to make an easy-to-triage report that is only accessible to those
running bug days?  Making such a list might be difficult (especially
since it could easily become depleted quickly), but I have a couple
ideas that I think might work and can mostly automate the creation of
such a list.  [Unrelated note: Ignore the last couple sentences of this
email if you've read everything up to here]

Bugmaster only info
I think there are a number of things that are only relevant to
bugmasters but which should still be collected into a clear coherent
place.  This can include (1) a HOWTO on upgrading bugzilla, (2) periodic
things that should be done (emailing a yearly "list of who closed the
most bugs", adding new version numbers after a major gnome release), (3)
guidelines and when to add products and components (I still am not clear
on the rules for that.  Perhaps other guidelines in general of this
nature as well could go here), (4) HOWTOs on general bugzilla-esque
things (e.g. how do I create a new "Gnome Version" or "Gnome Milestone")




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

Elijah

-- 
Elijah P Newren <newren math utah edu>