corporate win--their requirements
gerv at mozilla.org
Fri Sep 27 21:11:54 UTC 2002
Myk Melez wrote:
> A large corporation that I'll call Zippy has decided to adopt Bugzilla
> to track defects in its software products across a large development
> division with several thousand employees.
Fantastic :-) Looking at this list, I think that the Bugzilla
development team would do well to let Zippy's requirements set the
agenda for development for a period - this will benefit both us and
Zippy in the long run.
What sort of timeframe is Zippy looking at to get all these enhancements
made? This list looks like a fair amount of work - and some of it has
dependencies. For example, we can't do custom resolutions without
generic graphing, which is a fairly big hunk of code.
> Product and User Views
> Different products may have different bug tracking needs, especially
> when they are being worked on by separate teams, so it should be
> possible to customize the "enter bug" and "show bug" UIs (showing/hiding
> various fields) based on the product to which a bug belongs. Different
> types of users (development, QA, project management, etc.) also have
> very different needs and interests, so it should be possible to
> customize the UIs for each of these groups.
Does this require some sort of explicit support, or can this be done by
Zippy replacing e.g. search.html.tmpl with a custom "distributor"
template which analyses the requirements for that CGI/user/product and
then PROCESSes the appropriate custom template?
> Sybase Support
> Bugzilla should support Sybase. Zippy has already done most of the work
> for this, although maybe in a hacky fashion. We should have a clear
> idea about how customers should add multi-database support so people
> don't waste their time and ours doing it the wrong way.
This is bbaetz territory. But we should try our hardest to do this in
terms of generic database support, rather than "MySQL and Sybase".
> Custom fields
> It should be possible for the Bugzilla administrator to define custom
> fields in addition to the built-in fields. Custom fields should be
Is anyone on this list responsible for the current custom fields patch,
or are we going to have to find a core developer to shepherd it into the
tree (as MattyT suggested)?
> Third Level of Categorization (sub-component)
> It would be useful to have a third level of categorization in addition
> to product and component.
My company's (inferior, home-grown) bug tracker uses this also - it's
one of the key schema differences.
It does add some complexities, though - particularly in moving bugs
between products and components (more "adjust these fields" pages), and
you get a large amount of JS on the query.cgi page because it has to
carry the names of every product, component and sub-component.
I was struggling with this problem the other day for custom graphing. Is
there any way of getting JS to update form fields with values fetched
from a server, in a way that even works in Netscape 4?
Will this mean starting to require JS on pages like the search page?
> Custom Resolutions
> It should be possible to define the resolutions available to bugs on a
> product-specific basis.
Sidenote: I think we should be making the Product the configuration
barrier for a lot of things. Combined with the third level of
categorisation, we can start to make a lot of settings product-specific.
> Reopened Count
> It would be useful to know how many times a bug has been reopened
> without having to count rows on the bug activity page. This could
> appear right next to the status of reopened bugs.
This seems like a fairly simple RFE. Would it only have to appear when
the bug was in the REOPENED state, or would it also appear in the
> Pull-down Menu of Assignees
> It should be possible to select assignees from a list instead of having
> to type in their full email addresses.
This is a FRFE. We should do it by using a template to define the UI for
user selection wherever it occurs, and making that template do all the work.
Would the list be a global list of Bugzilla users, or restricted in some
> Time Zone-sensitive Date/Time Display
> Dates and times should be displayed in the user's time zone, not the
> server's time zone.
As far as I can see, this could only be done by having a user pref for
timezone. Web browsers don't send this info in a request. But this isn't
a particularly complex RFE. We need to centralise date and time
formatting anyway, for l10n reasons.
> Entry of International Data
> It should be possible to enter non-ASCII data into Bugzilla.
It is possible at the moment - as long as we use no charset, and rely on
browsers making intelligent guesses. The only other alternative is
making charset a parameter. But we need to test with charsets like UTF8.
This has been discussed before - what are the issues here?
> Project Management Fields
> There should be fields in Bugzilla for tracking project status, f.e.
> hours required to fix a bug, estimated fix date, etc.
Can you be more specific about exactly which fields are required?
There's a patch for this, I know. Can we implement this in terms of
custom fields, or does there need to be an interdependence between these
> System Configuration Fields
> There should be fields in Bugzilla for more specifically identifying
> reporters' system configurations (CPU, memory, etc.).
Can we not support this request using enter_bug.cgi comment-formatting
templates? Or do they want to query efficiently for all bugs filed by
anyone using a Pentium IV processor?
More information about the developers