Re: spec issue tracker

Erik Wilde <dret@berkeley.edu>, 2008-11-27 18:09 -0800:

>  Michael(tm) Smith wrote:
> > If you want to use it, the URL for entering a new bug is here:
> >   http://www.w3.org/Bugs/Public/enter_bug.cgi?product=Geolocation
> 
>  i just looked at it and it seems to suffer from the same side-effects than 
>  the others i have seen for w3c specs so far: a number of unnecessary fields 
>  (such as OS and platform),

Yeah, that is unnecessary-ness inherent in using a basically stock
(unmodified) Bugzilla install from upstream. FWIW, the W3C was
among a number of organizations that the upstream Bugzilla
maintainers surveyed a few months back, to collect specific
feedback on what improvements/changes they should make. We
collected some feedback from W3C users as well as the team, and
passed the details on to them. Henri Sivonen in particular was one
person I remember giving some very good feedback, and I think the
problem of the unnecessary fields like OS and Platform was one
that he also pointed out. So the maintainers are aware of that
being a problem, and perhaps down the road will give us an easier
way to suppress display of those in the UI (that is, without us
needing to resort to hacking at the source and then needing to
deal with maintaining a hacked/forked version).

>  and a shortage of spec-related concepts (such as 
>  "editorial", "spelling", "data model").

I've never had anybody mention wanting to have the kind of
granularity of detail as far as fields related to spec issues.
I can certainly see them being useful, but I think we'd wanted to
have some kind of finite list of what the most common ones are
that people would want, and I'd frankly doubt we could put
together such as list very easily or un-painlessly -- seeing it
would require discussion and agreement, across all the working
groups using the W3C bugzilla, about what the list should be.

>  is there any way we could configure bugzilla to better fit the
>  needs of a spec?

There may be a way. But as I alluded to above, figuring out how to
make it better fit the needs of a spec is not just a technical
issue of modifying the bugzilla config. It's potentially a
cross-group process discussion, and not one that so far it's
seemed like to would be all that productive to try to have.

>  also, currently there is nobody to whom an issue could be
>  assigned.

Issues don't strictly need to be assigned to anybody. But I expect
that if people in the group start actually using the bugzilla,
then it might make sense to set Andrei as the default assignee.

>  for my personal use, i switched to 
>  mantis because it was much easier to configure than bugzilla, but hopefully 
>  if you know what you're doing, bugzilla is not so hard to configure after 
>  all.

I've never really done any of the backend sysadmin-level config of
bugzilla -- only whatever config options are exposed through it
Web admin UI. I can't say I'm particularly fond of it, but it
seems adequate for the relatively limited uses it's put to as far
as what we do with it at the W3C.

>  thanks for the initial setup and i am looking forward to using this,

I hope it does end up being useful. As I mentioned in my earlier
message, I think one big benefit it provides is that it allows
public submission and tracking of issues.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

Received on Friday, 28 November 2008 10:22:08 UTC