When I think of components, I think of additional characterizations I can apply to an issue to track which components of my software solution might be impacted by an issue, or to provide context to another developer so they are aware of what code they will need to look toward in providing detail or corrective action based on that ticket. Instead, I create a component and I see it in my backlog of issues.
If my way of thinking on this is wrong, is there a better way to make these kinds of characterizations that is organized and "simple" to do?
For further education, if my way of thinking is in fact flawed for the design intent of components, can someone tell me what other advantage they would have to the organization of a board?
