Hi! Thank you for your thoughts!
I want to start by saying that community participation is a vital part of Flarum: after all, we're an open source project for the people. I think it's absolutely crucial that people feel comfortable commenting and disagreeing (as long as its respectful and productive, as you've done here): after all, more discussion and a better understanding of everyone's use cases leads to a better product.
Another thing I want to touch on is the balance between personal opinion and official decisions. When I comment something like flarum/tags#67 (comment), I'm expressing my personal opinion as to how we should proceed. That being said, official decisions are generally formed by consensus of core developers, which I am one of. For this particular PR, it might have been better to leave the PR open for a bit longer to allow for responses to my opinions, but then again. that PR had been sitting open for months with no discussion.
I'll also comment a bit on the decision itself. The main UI issues weren't with the admin dashboard, but with the forum. To name just a few:
- How would additional layers of tags be displayed on the tags page?
- How would the tags sidebar accomodate potentially infinite layers without covering half the page
None of these have obvious answers: we'd be looking at a total rewrite of the tags frontend.
Finally, it's important to note that tags is an extension. It's one that's widely used and officially maintained by the core team, but at the end of the day, it's an extension like any other, and could be replaced with a fork or an entirely new implementation if one emerged. That's what I was alluding to when I said:
maintaining their own fork
as an option for forums that'd like this functionality. Our main goal for core is to be as extensible and flexible as possible: that's why we keep it so minimal and relegate features that others would consider essential to extensions: We're not denying that those features don't matter; we dont want to force a rigid way of doing things on users. But while we also try to keep bundled extensions widely useful and flexible, those same flexibility requirements don't quite apply, and it's often up to the core dev team's vision for the extension.