corporate win--their requirements

[Gervase Markham]

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 
> product-specific.

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 
ASSIGNED state?

> 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 
way?

> 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 
fields?

> 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?

Gerv