A lot of thing have happened during these past years. We have gone from FreePBX 2.5 to the upcoming FreePBX 2.9 and it has been fun and educational.
But what do we actually do as a [b]Developer[/b] in FreePBX? The question arise from time to time and I decided to write something about what we do and how we do it.
First of all we fix bugs, that is the main priority. Then, between FreePBX releases, we add features to FreePBX.[size=15]What is a Bug, and what is a Feature Request?[/size]
A [b]Bug[/b] is when something is broken in FreePBX.
By broken we mean that something does not work when you call into the system (or call out) due to some error in the Asterisk dial plan. Most bugs are detected in the alpha or beta release.
Then there is the [b]Feature Request[/b], that is when someone wants to have a feature in FreePBX that he or she find useful.
This is something that extends the functions and features in FreePBX. A feature request can be for inclusion of more fields in Extensions, like new peer settings when using Asterisk 1.8
The decision is made by the developer that first read the ticket, he first try to duplicate the bug, if the ticket is found valid and the Developer can duplicate it, it stays as a bug. When the ticket is examined it is also checked if the posted details in the ticket can be valid as a bug. Sometimes the ticket is changed to a Feature Request, the poster want to have a function in FreePBX that extends the current implementation.
A ticket change it’s not a matter of ‘right or wrong’ as both the reporter and the developer may be correct from their perspective. For the project, the developer base the ticket change from the amount of work to address the desired change which may involve incremental development and/or testing of various scenarios vs. ‘fixing’ some ‘broken’ scenario.
[u][b]A ticket change should never ever be taken personally[/b][/u], we base ticket changes from the reported issue, not by the reporter.
As a reporter, someone may run into an issue that they consider major or even critical for what they are trying to achieve. As a project, we will try to assess the relative priority based on both existing bugs as well as our judgment as to the impact on the project and user base as a whole. None of these changes should ever be taken personally and we are also very capable of making mistakes whether in such changes, or even closing bugs for any reason. You are always welcome to ask why something was changed or respectfully disagree providing your reasons why you think something should be different. We have made plenty of mistakes in the past as does everyone and making changes once things are civilly discussed is very easy for all parties involved…[size=15]Do I get payed to work as a Developer for FreePBX?[/size]
No, I don’t, I do this mostly on my spare time. The company in Sweden were I work have been using Asterisk and FreePBX for about 4,5 year now.
It is a busy system with a lot of queues and ring groups. We currently have 5 locations, 90 SIP phones, 326 DID’s and one server. We use SIP all the way.
Most of the bugs in FreePBX that I have found was from using FreePBX at work. Ticket 3963 was discovered when I added a new extension and our support department came and asked if there was something wrong with the PBX as they have not received any calls since an hour and a half. The time spent on fixing that was donated by my company.
A ticket that I looked into was #3805, I helped out by adding extra detection for certain HANGUPCAUSE, timboothby filed the ticket and nicson provided some details and code that I could use, Philippe have provided a new module, Route Congestion Messages, that we added the code to.
We needed this at work as we use Grandstream phones, and they have a default timeout of 4 second before the phone automatically dials the number, but sometimes a person begin to dial a number, pauses for some reason, and they get “All circuits are busy now”. With the addition of HANGUPCAUSE 28 I could record a message that says “The number you have dialed is to short”.
I also have taken under my wings two modules, Bulk DID’s and Bulk Extensions, as I find those two modules quite useful. By doing that, those modules are now in the main repository for FreePBX and are maintained on a regularly basis.
I do hope this blog will let you understand what choices we make regarding tickets and why we decide how to classify them.
From time to time we get appreciation from users that find FreePBX valuable (thank you), sometimes we get bashed for doing things that one or two dislikes.
But we continue our mission, to make FreePBX the best GUI for Asterisk.