FreePBX Ticket Reporting - Legacy
The content on this page is superceded and is kept for archival purposes. Please see this page for the current FreePBX ticket process: FreePBX Ticket Reporting
- 1 Overview
- 2 Expectations
- 3 Ticket Lifecycle
- 3.1 Triage
- 3.2 Needs Information
- 3.3 Open (Development State)
- 3.4 Dev Review (Development State)
- 3.5 In Progress (Development State)
- 3.6 Selected for Development (Development State)
- 3.7 On Hold (Development State)
- 3.8 Resolved (QA State)
- 3.9 QA New (QA State)
- 3.10 QA Progress (QA State)
- 3.11 QA Review (QA State)
- 3.12 Closed
- 3.13 Admin Closed
- 4 Keeping your report alive
- 5 Derivative works
- 6 Support Request
Overview
Open tickets against FreePBX is a simple process.
Open source issues can be reported at: GitHub - FreePBX/issue-tracker: The unified FreePBX issue tracker. 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
Please note that tickets are handled through a triage system and may not be handled in the order received.
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.
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.
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
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
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