When reviewing cases in the support log, they will be sorted in a natural action-item order. The version column indicates what version the user has in which the issue as noted. Priority indicates when it might be addressed. Developers will use the filter action to look for their own cases for specific development milestones.

You can also enter descriptions in this field such as ‘Gift Certificate’ to find all issues with those words in the title or the text of the case. See the FogBugz help for more details.

Description

This is the general description of what is wrong. Depending on the source of the issue there may be step-by-step instructions to reproduce, or just a blab of text asking for something to work a certain way. If you don’t understand the description, get clarification from the submitter or the correspondent. The submitter is the person who created the task (‘opened by’). The correspondent is the email address of the customer who submitted or reported the issue.

For all Bugs or Support Issues

Enter a longer description of the problem or issue at hand, including the steps to re-create the issue. If appropriate, including specific patron numbers, order numbers, ticket numbers (or ticket section/Row/Seat/Event/Performance), shows, shopping carts and attach screenshots using the 'Attach File' link at the bottom of the screen.

• Enter the correspondent's email address if the incoming item is a phone message
• Assign to a staff member (normally yourself, but could be second level support>
• attach or relate to any prior sub-cases that you are aware of or are in the links
• Estimate the amount of time that it may take to solve the issue
• Enter the version of the software in the form VXXXXX - such as V82501 - that the user experienced the issue with
• Indicate what operating system that the user illustrated the problem with

For New Development

For new development tasks, or task transferred from support to development:

• enter the estimated due date (or date that the customer might want the item) if there is a deadline
• Assign the task you 'unassigned development'
• Change the 'project' from 'Inbox' to 'Theatre Manager'
• Change the area that the problem is in to categorize it. That way, when code is opened up, we can look at other tasks in that area and resolve one or more issues, or see how often the issue has been reported
• Indicate the approximate release we may wish to release this code

History of a bug is obtained simply by clicking on it. This tracks a chronological view of every change made to the task, who changed it, and comments relating to the change and why. It could be thought of as a ‘long email’ with a historical trail.

Sometimes, a client may submit multiple issues that may, in fact, be related. You can view them simply by running your mouse over the other cases sent by the correspondent.

If cases are deemed related, they should be filed as ‘sub-cases’ of the main case.

You can also see the entire history of the corespondent by clicking on the email. Click on the first half to see that person, click on the domain name to see everything from that domain (or company)

• Proposed changes in the text area
• Estimate in the estimate area
• Set the category, area, milestone as required
• Associate any sub cases

Replying to the originator (which could be a customer) means finding the last thread where the customer corresponded and replying to that with your resolution and the proposed version in which the fix will be released. Add any links to online help in theatremanagerhelp.com that are pertinent to the problems.

Start by selecting the category of issue that this will be, then use the following guidelines.

• Bug – This is a defect in the application
• Feature – This is a change to the functionality of the application
• Inquiry – This is a query about how the application works
• Schedule Item – This is a proposed new feature for the application that has not yet been approved

Emailing Cases

When a case has been created and assigned to you (perhaps by another person), you should also receive an automatic email with the case number and a link to the case so that you can find it quickly. If you reassign a case to another person, they will then get an email.

It is recommended that you have a separate 'case' folder in your email program and use 'mail rules' to move cases there automatically. Anything that is unread is, of course, new or has a change of state.

Mail will keep those threaded for convenience.

1. Edit the case
   1. Change the project to Theatre Manager
   2. Category to bug or enhancement
   3. Area to reflect the part of the application that was changed
   4. Who completed the task (if it is different than the assignee)
   5. And the release number milestone that the fix is targeted for
   6. Fill in the estimate if it was not already filled in.
   7. Add notes about the resolution. This is probably similar to the VCS notes.
   8. Click OK to save the changes.
2. Set the the case to be tested
   1. Management will assign a tester to the case to confirm functionality
   2. This should include visual inspection of the code where appropriate
3. Then, resolve the case and provide:
   1. The actual hours to resolve the issue
   2. Add release notes that are suitable for providing to the customers and pasting into the theatremanagerhelp.com release notes.
   3. Close the case