The Need for Custom Fields [was Re: The Road to 2.18]
louie at ximian.com
Tue Mar 9 14:32:37 UTC 2004
On Tue, 2004-03-09 at 08:38 +0000, Gervase Markham wrote:
> Christopher Hicks wrote:
> > Still!?!?!? One would think after as many times as we've been around this
> > topic that some concensus might have developed. The inability of the core
> > bugzilla developers to grapple with the desirability of custom fields at
> > this point is truly surprising.
> Have you read Joel's article?
> That's a big part of the reason why some people are reticent.
Joel's argument, as usual, is 'I'm the center of the universe, and it
wasn't necessary for me, so it isn't necessary for you.'
I'm as against software options as anyone (see
http://www106.pair.com/rhp/free-software-ui.html for some stuff I
strongly believe in), and I suffer daily from the poor choice of
additional bug fields in bugzilla.ximian.com. So I agree that 90% of
additional bug fields put in by admins are a waste of everyone's time,
and should be avoided.
However, bug tracking systems are systems targeted at experienced expert
users with often idiosyncratic needs. Expecting one size fits-all to
actually work across the wide variety of distribution and development
models out there isn't sane. Furthermore, it is something where poor
field selection can make a piece of software nearly useless, unlike more
general purpose software where the lack of an option can be irritating
but usually not a showstopper. So those last 10% of genuinely useful and
important custom fields are hugely important- they can make the
difference between using bugzilla and not for many people.
It impacts me in real life- not only is it a pain to get the fields I do
need in b.g.o and b.x.c (talk to me about the 10K nasty keyword hacks we
all have to use) but it is costing us users. Novell's development tools
people were on the cusp of offering to switch the entire company over to
bugzilla- but can't, and this is the killer. [Yes, they abuse custom
fields horribly- but there are some that are very reasonable for how
they do development internally, and it would not make sense to get rid
Anyway, I can rant on and on about this, but I probably shouldn't. :)
More information about the developers