FreePBX Ticket Reporting - Legacy

Overview

Open tickets against FreePBX is a simple process. 

Open source issues can be reported at: http://issues.freepbx.org/  using the same account you have used to access all of the FreePBX EcoSystem.

For commercial modules see: This Article

Commercial module tickets will be closed and you will be forwarded to the above article.

Expectations

1. Please note that tickets are handled through a triage system and may not be handled in the order received.

2. Our team monitors the bug tracker for blocker and show stopper issues but most tickets will be reviewed by members of the development team on the first business Monday following submission.

3. Tickets may be resolved within minutes or it may take much longer. Please note a team member may change the priority - please do not change it back. The time it takes to resolve a ticket also depends on the effort required to resolve the issue. For all issues we must be able to reproduce the issue to fix it.

4. Please do not ask for ETA's or timelines. If a developer has this information it will be passed along. Note all the information is contained in the ticket.

Ticket Lifecycle

As processes change and improve these states and the ticket life cycle may be updated

After a ticket is created, there is a workflow that is used, so that you (and everyone else) can see what the status of your ticket is. 

Triage

This it the initial state all open source ticket start in. Once tickets are triaged they go into the open state. Ticket "triages" happen roughly every Monday. A ticket at this stage might be rejected if it's not a valid ticket

Open

There are three actions a ticket can perform from Triage:

• Approve: This will transition into the Open state

• Reject: This will transition into the Closed state

• Needs Information: This will transition into the Needs Information state

Open

Needs Information

When you see the Status as NEEDS INFORMATION that means the ticket is awaiting a response from the original submitter. If there is no reply within two weeks time the ticket will automatically close. It may be reopened it if you can supply the needed feedback.

There are three actions a ticket can perform from Needs Information:

• Triage: This will move the ticket to the Triage state

• No Information: This will move the ticket to the Closed state

• Open: This will move the ticket to the Open state

Open (Development State)

This is the state a ticket reaches right after triage. It may or may not be assigned to a developer.  Any bug in the Open status is considered as a new bug. If it has been assigned to a developer, it means that the developer has been allocated this bug as part of the Triage process. Another developer may take this bug, if they want. If another developer wishes to work on that bug, they should contact the developer who is currently assigned to this ticket. 

There are four actions a ticket can perform from Open:

• In Review: This will move the ticket to the Dev Review state

• Make New QA: This will move the ticket to the QA New state, skipping development

• Start Progress: This will move the ticket to the In Progress state

• Resolve Issue: This will move the ticket to the Resolved state (it is not closed)

Dev Review (Development State)

This state was formerly called "In Review". Several states also call this "In Review" as a transition. A ticket should be in this state if there is an active Pull Request Waiting to be merged

There are three actions a ticket can perform from Dev Review:

• Resolved: This will move the ticket to the Resolved state (it is not closed)

• Start Progress: This will move the ticket to the In Progress state

• Review to Reopened: This will move the ticket to the Open state

In Progress (Development State)

When the Status is set to IN PROGRESS that means the team member has added it into their current work queue. Note developers may be actively working on multiple projects or issues. This state may last minutes or weeks depending on the issue. 

There are five actions a ticket can perform from In Progress:

• In Review: This will move the ticket to the Dev Review state

• Resolve issue: This will move the ticket to the Resolved state (it is not closed)

• Wait Progress: This will move the ticket to the Selected for Development state

• Stop Progress: This will move the ticket to the On Hold state

• Open: This will move the ticket to the Open state

Selected for Development (Development State)

This means the ticket has been selected for development but is not currently in progress. It should be in progress shortly

There are two actions a ticket can perform from Selected for Development

• Resolve Issue: This will move the ticket to the Resolved state (it is not closed)

• Start Progress: This will move the ticket to the In Progress state

On Hold (Development State)

This means the ticket us in an indefinite hold.

There are two actions a ticket can perform from On Hold:

• Resolve Issue: This will move the ticket to the Resolved state (it is not closed)

• Start Progress: This will move the ticket to the In Progress state

Resolved (QA State)

This means the ticket has finished the development cycle and is now awaiting the QA cycle. The ticket is finished from the developer's point of view.

There are three actions a ticket can perform from On Hold:

• Start QA Progress: This will move the ticket to the QA Progress state

• Reopen Issue: This will move the ticket to the Open state

• Close Issue: This will move the ticket to the Closed state

QA New (QA State)

This ticket is awaiting the start of the QA cycle. The ticket has skipped development completely.

There is one action a ticket can perform from QA New:

• Start QA Progress: This will move the ticket to the QA Progress state

QA Progress (QA State)

The ticket is currently in progress as part of the QA cycle.

There are two actions a ticket can perform from QA New:

• QA Review: This will move the ticket to the QA Review state

• Reopen Issue: This will move the ticket to the Open state

QA Review (QA State)

The ticket is currently in review as part of the QA cycle.

There are three actions a ticket can perform from QA Review:

• Close Issue: This will move the ticket to the Closed state

• Reopen Issue: This will move the ticket to the Open state

• Make New QA: This will move the ticket to the QA New state

Closed

The ticket has been closed. Comments are still allowed

There are two actions a ticket can perform from Closed

• Admin Closed: This will move the ticket to the Admin Closed state

• Retriage Issue: This will move the ticket to the Triage state

Admin Closed

The ticket has been closed and no comments are allowed

There is one action a ticket can perform from Admin Closed

• Closed: This will move the ticket to the Closed state

Keeping your report alive

Bug issues may be closed for several reasons. It is important that you provide quality and timely information. Note the bug system is for bugs and is not for general questions, commentary or arbitrary discussion.  If you are unsure that your issue is actually a bug it is best to first discuss the issue in the forums at http://community.freepbx.org.

Things that should generally be reported as bugs:

• Unhandled exceptions such as "Whoops Errors" including what you did to make it happen.

• Spelling and grammatic errors.

Things that may be your browser, and should be tested in another browser or in the browsers safe/privacy mode:

Make sure you are running the latest updated version of your chosen browser. When filing browser based bugs ensure you provide the browser and OS along with versions.

• Form fields auto filling (password fields and prior text input).

• Javascript/Validation errors

• Weird visual display

• Missing Elements

Our team must be able to:

• Understand what your actual issue is.

• Reproduce the issue or see the issue clearly happening in logs.

To do this they need quality information.

Quality information is:

• What is not working

• What you expected it to do or not do

• What it actually did or did not do

• Relevant log sections (please obfuscate private information)

• Relevant Call traces (please obfuscate private information)

• Specific Version numbers

• Specific Hardware models

• Firmware and boot loader versions

• Relevant configurations (please obfuscate private information)

Quality information is NOT:

• 100,000 line log files

• Vague statements like "doesn't work", "I'm using FreePBX"

If a ticket does not contain enough information a team member may ask you for more information. It is critical you provide this in a timely manner. If no information is provided and the user does not provide a timely response the issue may be closed as invalid.

Derivative works

If you are using FreePBX as part of a derivative project and have not obtained it directly from FreePBX it may be best to start with your project maintainer. They may modify FreePBX or restrict updates. Issues may already be fixed or may not exist except with their modifications. Some of these maintainers will file a bug with us as they know their modifications and can provide more information. Some maintain their own patches and may not stay fully up to date.

Support Request

Please note the bug system is not for general questions or support requests.  If you think your issue may be configuration related please use the proper support channels. Bugs are items that affect more than one user with known good information. Bugs are typically items that can be reproduced by following a recipe.

• Wiki: http://wiki.freepbx.org

• Community Support: http://community.freepbx.org

• Paid Support: http://support.schmoozecom.com