PBX Gaurdian Dev Wiki

PBX Gaurdian Future Versions Development Wiki

Guidelines for Bug, Support, and Feature Ticket Submission

  • Read through existing cases and see if your reporting something that's already being discussed. In some cases, there may be development forum discussions going on - be sure and check there also. Participate fully, but try to avoid duplication where possible.
  • Its very important for the developer or support person to be able to reproduce your concern - so provide concise information about how to do that.
  • When starting a ticket, do not assign a developer, establish a time line, or anything in that area. Let the developers figure that out.
  • When starting a ticket, for Target Version, Select the "Future Versions" entry on the list. The developers will later determine which version to assign the case to.
  • Stay calm. We realize that experiencing difficulties can be frustrating. Try and remember, we really are on the same side as you. :)

It is everyones goal to make our time here enjoyable and productive - and together we will make software better, one step at a time.

Support Ticket Status and Workflow

There are eight different statuses available when creating, or updating a bug, feature, or support ticket in this system. These statuses are used to assist in the workflow of processing a tickets.

  • The first phase for most tickets is the "New" phase. When creating a ticket, always select the status "New". A ticket in the status of "New" is awaiting review by a project manager.
  • Project Managers will review tickets marked as status "New". After review, the project manager may select from several statuses depending upon the action determined for the case. If the project manager is uncertain whether or not the ticket will be worked on immediately, or by whom it will be worked on, they may leave the status as "Reviewed" - Intel such a time as that information is available.the project manager may elect to assign the ticket to an individual developer, in which case the ticket status will be set to "Assigned". Developers may also assign cases to themselves, or to one another when working as a team.
  • After a ticket has been completed by a developer, the ticket status should be set to "Resolved". Tickets in the "Resolved" status are awaiting software Q.A. test. Most projects have a QA test process before a case is marked
    "Closed".
  • When a ticket has been accepted or assigned to a QA test person, the status of the case Shall be "QA Testing".
  • After a ticket has been through the project's QA test process, the tester will either set the ticket to status "Closed" (if the QA test cycle confirmed that the topic of the ticket has been resolved), or the tester will return the ticket to its previous status, being either "Reviewed", or "Assigned", if the QA test process was not successful.
  • The "Rejected" status is reserved for bug tickets who's complaint cannot be reproduced, or who's feature requests has been turned down by the project manager. Appropriate notes should be made in neither case.

Due date, Estimated time, Logging time and Percent completed.

The due date, and estimated time on a ticket is generally set by the project administrator, in consultation with the assigned developer. The due date is used in conjunction with the Gantt chart, to determine when tasks are running longer than expected.

Logging time is an important part of completing data entries when handling a ticket. Not all ticket entries require a time log entry. Case entries whose primary purpose is an exchange of information, for example, do not generally require time log comments activities or spent time data, simply filling in the begin Notes" field is sufficient in these cases. Case entries which describe the completion of either project design work, development work, or software test do desire a log time entry, as well as notes entries when updating the ticket.

Also available in: HTML TXT