One advantage large companies have over smaller ones is that they can use the economics of scale to install unifying systems for large portions of their operations. Think SAP or Oracle Applications. One step along the maturation process of a company is to recognize the need/want for this type of system, but not being able to afford it. This post is how I see a small / medium size company could use Bugzilla to manage their software from both an internal perspective, and from a partner management perspective.

In my vision, Bugzilla almost can be called Changezilla as all items relating to the changing of the product would be managed in a central repository. The central means of managing this is through the use of Groups. Before I list the gropus I would utilize, a bit about terminology.

  • Bug – This is ‘something is wrong with the product’ — a form doesn’t work for example
  • Change – This is ‘please change something in the product’ — a copy/content change for instance

The following are the groups I would create.

  • Admin – Can do anything to any record. Limited to the internal owner of the system. The Change Manager or someone from Systems for instance.
  • Development – This group includes not just the programmers, but QA too. Limiting it to just programmers and creating one specifically for QA would eventually mean merging roles in the long run when programmers are tapped to be testers in a crunch. Members of this group can:
    • Log bugs
    • Modify bug state following the prescribed lifecycle
    • Modify change state following the prescribed lifecycle.
  • Development Leads – Basically, the same as the Development group, but with a little more power:
    • Log bugs
    • Modify bug state outside the prescribed lifecycle
    • Modify change state following the prescribed lifecycle.
  • Account Management – This group is comprised of members of the Account Management team. These people are who deal with partners on a day-to-day basis. As a result, they can:
    • Log bugs
    • Log changes
    • Modify bug state following the prescribed lifecycle
    • Modify change state following the prescribed lifecycle.
  • Account Management Leads – The senior Account Management members go in here. In general, they have more rights in the system than development which is okay. Unhappy partners are partners who are looking for either another organization to partner with or better terms to stay with you; neither one of which is all that good.
    • Log bugs
    • Log changes
    • Modify bug state outside the prescribed lifecycle
    • Modify change state following the prescribed lifecycle.
  • Partner Specific – Each partner should have it’s own group to which individual partner accounts are assigned to. Having a single partner login reduces the traceability of bugs, so create 15 accounts if that is how many are needed. The security around these groups needs to be pretty tight. Note too that their
    • Log bugs
    • View bugs logged by the group members
    • View bugs for their products that have not been logged by group members but have been flagged as partner visible
    • Close bugs logged by group members which have been assigned to them (for instance, when a bug is identified in UAT, fixed by dev and verified by QA, the partner needs to accept the fix)

Please poke holes in this plan as we’re discussing this currently at Points