Tony, I am not sure if you intended on putting a link into you last comment, I did not see one, but I think this is the general accepted definition of a bug: https://en.wikipedia.org/wiki/Software_bug
Re-producability has nothing to do with whether a behavior is a bug or support issue, but I do understand that if you cannot reproduce the issue, you cannot fix it, and in fact, you may need to close a bug ticket for that reason. That still does not make it a support issue. A support issue is a behavior that is a result of the mis-configuration or misuse of software resulting in undesired behavior. In the example of FREEPBX-14517, presumably this was closed because it could not be reproduced…that makes sense, if you cannot reproduce it, you cannot fix it. But what does not make sense in my mind is that it was labeled a support issue. Later when I raised this issue again and another user also related the same issue, userman v22.214.171.124 was produced to fixed the login issue…so clearly this is a bug, not a support issue.
Andrew asked at one point “My honest question is what do you think a ticket gains you over the forum thread?” My response to this is two fold, first, as a user, to be honest, it doesn’t matter at all, as long as the issue is resolved, so as a user, i would concede this and stop using issues.freepbx.org But, from the FreePBX perspective…I would think it matters quite a lot. I would think that someone would want to see bug report metrics, to understand how many bugs are there, how many have been resolved etc. If something is worked on in the support forums without a bug report…then that skews the numbers. But maybe no one is looking? Anyway, those are my thoughts today…I am open to hear yours.
Wiki definitions aside, the FreePBX issue tracker is intended for actionable items only. The issue tracker makes a very poor tool for diagnosing issues, so a bug ticket must contain enough information to indicate to whomver is working on it what is wrong. A mere description of the problem is usually not sufficient, unless the issue trivial. Sufficient support documentation might include any or all of the following:
A call trace (if it’s a call handling issue)
steps to reliably reproduce the issue on another system
log lines from any of the various system logs
Full content of Whoops! error if one is displayed
There are times where the reporter has not provided enough detail to make the issue fully understood to the devs, in which case the reporter may be tasked with providing additional specific information. In cases where it’s not clear what additional info is missing, the reporter is asked to open a discussion in the forums. The point is to expose the reporter’s complaint to as many eyes as possible, to interact with developers and users in an effort to crowd source full details. It is much more difficult to diagnose issues in the issue tracker (nearly impossible really) as it has virtually no traffic.
The tl;dr of this is discussion belongs in the forum; tasks go to the issue tracker. Deviation from this results in the issue tracker filling with non-actionable tickets and bugs going unfixed for longer.
The point to sending it back to the forums is to have open dialogue and get others involved and hope someone can reproduce it and provide more information. We call that support as it can not be a bug report yet if we can not reproduce it. Maybe calling it support is wrong but that is the terminology we have used for years when something is not reproducible.
Lorne, I hear what you are saying about what belongs in forums vs the issue tracker and if that is the way it is then thats fine, but I don’t think that is intuitive and I don’t think (hope I did not overlook this!) it is stated anywhere. I think you should make that clearer to new users…“ask the forum first, the put a ticket in if instructed to” Also, is that is the same for feature requests etc? should everything go to forum first?
Tony, I think you are right, i am getting hung up on the term support issue. As I am in support myself, I take it to mean something else.