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 follo

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.