For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.
"UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works?
It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a different search. Having the platform last seems strange to me, though.
Yeah, often I get into a problem where I wanted to have a hierarchical tree to organize my things and then later I wanted to somehow connect nodes from different branches in some way. I guess you could always have `ui::app::android ui app android` if needed
hrm.. I guess I could see that being useful in some cases. It might make discovery a little harder for someone that doesn't know the hierarchy, but I could see that being useful for people that know the hierarchy in an org that has a massive amount of stuff to label. I guess I just like key/value tags better than labels to organize and filter through data. They seem a little more self explanatory and I think they obviate the need of a hierarchy in the tag key naming.
