A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.
I think the reality is that software is very rarely specified enough that you can go to a central specification and point at it and say "look here in the spec it says it should do X"
Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug".
It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature!
And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time.
Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.
Sure, sometimes someone with the ability to do so needs to make a call and decide if the issue is to be treated as a bug or a feature request. It does not follow from it that planning and bug tracking are the same thing and are best done with the same tools.
Work tracking is also not the same as bug tracking (or planning!), and it is not obvious that all “work” meaningfully goes into the same queue. A dev lead with a basic grasp of context switching costs and specialised knowledge will instead look at several streams and organise accordingly.
It absolutely makes sense to keep planning separate, if for no other reason than the planning process and details rarely benefit from being exposed directly to the users.
Bug reporting and fixing on the other hand is at its best when it is fully open, and is a valuable resource for users.
Say one of our users clicks a button and expects our program to do X but it does Y. To the user this is a bug, regardless of the underlying reason, and it might be an urgent blocking one as such.
What's the value of tracking such "bugs" in one of two places, depending on the underlying reason? In either case I might have to get the button to to X in a couple of hours.
