Using Groups to simplify Separation of Roles and save your developers

  1. This is not at all unreasonable, in fact it's a noble goal.
  2. It happens that this is not hard to do w/ Bugzilla.

Setting up Products

When you create the products, let the system create a group for each {I generally don't play with groups, so you'll have to bear with me on the next bit.} The developers product should be set for mandatory/mandatory and entry on the developer group. This will prevent people who aren't in the developers group from seeing or filing bugs in the product. For the customer facing product, set mandatory/mandatory for the customer group, but you don't need to set Entry.

How it Works?

  1. The customer files a bug (in a Customer facing product).
  2. The bug is automatically assigned to someone in Support.
  3. The person in Support files another bug (in a Developer facing product) and marks it as blocking the customer's bug. {Whether you use Dependent or Blocking is an implementation decision, make sure Support is consistent.}

Why it Works?

Since Support filed the developers bug, the actual person in Support will get mail forever about that bug {you can of course use the QA field and set it to some Support user since in all likelihood the Support reporter will change rolls eventually}. When a bug is resolved or something else of interest to Support, emails will be sent to the reporter (someone from Support) {and if you're using QA, another person from Support}. Someone from Support then simply annotates the customer bug. When the customer provides info in the customer bug (which is assigned to someone in Support), the Support guy gets the mail and annotates the developer bug.

What advanced things could you do that might simplify and yet eventually frustrate your developers?

If you're willing to let your developers ask or accidentally ask the customers questions, or see the bugs, then you can put them in the customer group

{note, there might be a way to let someone only read bugs, in which case, sticking the developers into a read-only flavor for customer bugs might be OK, unless your customers are rude/annoying.}

How do you scale to multiple products?

You could have products with similar names. Alternatively, perhaps you would use the codename for the developer products :).

There are other ways of course. There's also a meta category beyond products (called classification).

How do you provide privacy to customers?

Instead of making the Customer facing product Entry Mandatory/Mandatory for Customers, make the Customer facing product Entry NA/NA for Customers and (Not Entry) Mandatory/Mandatory for Support.

What are the drawbacks to the paired product solution?

It's a bit annoying, and perhaps not quite ideal. If you think about it further, it probably isn't so unreasonable. For example, the components you give in a customer oriented product might not really need to correspond in a one to one fashion with how the product is actually organized for engineers.