Separating Customers from Developers using Bugzilla Separating Customers from Developers using Bugzilla

How can you keep customers and developers separate from each-other?

Communication between customers and developers should be channeled through the support team. Prevent customers from seeing who is working on the problem.

Why would you want to do this?

Not doing this results in customers calling and giving the developers a hard time).

Does the solution scale to multiple products?

It's amazing how demanding customers can be. :)

How would you keep different customers from seeing other customers' bugs?

This is perhaps because the customers value their privacy.

Bleeding extra errors in default configurations Bleeding extra errors in default configurations I browse the web on rare occasions. I frequently seem to encounter sites like <apache.example.com>.

Would someone please explain why that content is so common?

I have to conclude that a default configuration of apache from some vendor includes restrictions which result in the additional error.

Why does apache bother telling end users about additional errors relating to error documents?

This just puzzles me.

Why isn't that be restricted to error logs?

I can't explain it at all.

How does an additional error about not finding ErrorDocuments give the user a *better* experience?

I think it is, but instead when I get these pages, I always feel like my experience is *worse* than it would be if there was no magical ErrorDocument handling.

On Customizing Bugzilla On Customizing Bugzilla Suppose you have an established QA process and are transitioning from an established tracker (ClearQuest) to Bugzilla 2.16. What changes might you want?

I recently saw a real company make real modifications. Most of the changes are depressing, we'll see an example bug entry form (<enter_bug.html>), an example bug (<show_bug.html>), an example bug activity (<show_activity.html>), and the query page (<query.html>). Some of the ideas behind the changes are good, but perhaps people can find a better way.

Background (Bugzilla 2.12)

Note that one requirement of any tracking system is a complete change log. Bugzilla normally does this by refusing to allow comment deletion / modification and storing any other changes in an activity log. The log has a per field length limit (256 bytes?), when a field is longer than the limit, the change is recorded by splitting it into multiple change records.

A long time ago, the CC fields was a single text field and Bugzilla suffered dataloss because changes in the activity table didn't deal well with it. But even before then, simply reading changes to the CC list was hard because most of the string was the same. As someone experienced with Bugzilla and the activity log, this is something that I remember with dismay.

Requirements of a converting QA team

A good bug has:

• steps to reproduce
• expected results
• actual results

QA needs to be able to see:

• build tested
• build verified

Engineers need to be able to mark bugs for:

• release noting

Requirements of a customer oriented company

• for categorization and because we will not be giving everyone access to the bug tracking system, there must be a way to tag a bug as reported by:
  1. customers
  2. QA
  3. development
  4. marketing
  In ClearQuest there's a related use case field, such a field shouldn't really be a problem for Bugzilla, but if you're new to Bugzilla you're likely to reinvent it anyway.

Improving Bugzilla's Flexibility to Satisfy QA Needs Improving Bugzilla's Flexibility to Satisfy QA Needs

QA Fields

How should Steps to Reproduce, Expected Results, and Actual Results be handled?

Four related widgets:

• Comment [#1 by foo @ time |v] contains the current (...).
• An iframe shows the currently selected comment.
• Link to comment
• Update link, which copies the currently selected iframe text to the comment field and changes the Comment select to [Newly submitted comment|v].

If someone wants to update the steps to reproduce, they'd click the link by steps to reproduce and be scrolled to the comment where the current steps are, they could then copy the steps to the comment area and change