Most issue trackers are targeted towards developers. But when working in a small team that includes business people: does it makes sense for them to put non-dev issues inside the tracker?
I must say I have never heard of that combination. In my full-time job the business things are done somewhere else. But in a startup where you have limited cash, why not put business todos and dev todos in the same tracker?
To me, as long as there are appropriate filters and queues (so developers are not overwhelmed with tickets about "call Bob about new contract") combining them makes sense.
In my line of work (financial software for external clients), most of the dev issues will require prioritisation from the business anyway. At the end-of-the-day, they are all issues with the client relationship (does the software do what the client wants or is there a bug? have we found an issue in the code which will make the code less maintainable and affect our ability to keep clients happy in future? does client need a new contract?)
The combined approach may also help find non-technical solutions to technical bugs
why not. Redmine (for example) comes with 3 trackers out of the box and allows you to create more. The 3 are bug, feature and support.
bug is obvious, but is feature request a developer thing, or more a design/management issue? What of support - it might not be a bug but a configuration issue.
You can easily add Requirement to the list.
The benefit of adding all these to the same tracker tool is that you can then link them together. Imagine someone creates a feature request that goes through several modificatons through discussion with architects or designers. When management decides to implement this, it can be associated with a 'work' tracker item for you to check your source against, and then associate it with a 'test' tracker as it goes through QA, and then can be associated with support or bug items in the future.
This is called 'traceability' and is huge thing with large scale or very controlled software projects. As long as you don't add onerous workflows to it (ie only a team lead can create a work item, etc) then its a very good thing.
I would keep a tracker to maintain issues raised by business users. This is especially useful when doing requirement gathering. You might want to use the same tracker when you do user acceptance testing to tick-off existing issues or gather feedback from users. I have mostly used multiple excel sheets in same workgroup to maintain various issues(dev issues in one sheet, business issues in another).
