Issue trackers work perfectly well in the small and there are plenty of historical examples of successful issue tracker implementation among small, tightly scop

Issue trackers work perfectly well in the small and there are plenty of historical examples of successful issue tracker implementation among small, tightly scoped products with good communication. The problem is, as it scales, you have to start making tradeoffs between the different desires everyone has over what an issue tracker should be. Does every issue have to go into the issue tracker? If I spot a typo on the about page, do I have to file an issue or can I just IM Lisa and she can apply the fix? Does the issue tracker have to reflect the ground truth at all times? If a defect was assigned to Bob and Bob and Lisa have lunch in the cafeteria and Lisa figures out she can fix the issue better, does Bob then have to go back to his desk and reassign the issue to Lisa? Is the issue tracker for employees only or for management as well? For product companies, tracking time is generally unimportant but consulting companies generally require each hour needs to be billed to a particular client. Tying together the issue tracker with the time tracker seems like an initially appealing solution to this problem but now introduces a whole new world of pain. Is the issue tracker used for prioritization or is a separate system used? Both have pros and cons. Generally, when you hear people's gripes around issue trackers, it's not around the particular software but the policies surrounding it. But the reason why you hear so many complaints about the policies is because the intrinsic structure around how issue trackers are built actively encourage bad policy because of how many conflicting goals it purports to solve.