It feels a little weird to choose a category based on “who is most likely to fix it”. Would you also say a blank forum because of a global display: none isn’t a bug because a designer will fix it?
And of course you can say “it doesn’t matter, simply select one, we can move it” but this only helps for posting. When I try to find prior reports I would search for both of these issues in UX. Would it be possible to track responsibility for fixing independently from categories?
10 个赞
I am with you, this is extra confusing, it is very hard for operators to know what to do here.
@tobiaseigen / @jordan.vidrine any thoughts about this problem.
@Moin any suggestions about how this could work better?
I guess one alternative is to simply have stuff live in feature/bug unconditionally and use tags to denote ux.
Its a tough one for sure.
4 个赞
This seems like a good solution to me. It is obvious which category to post to, and those who care about UX can watch that tag. Another bonus is that we are able to eliminate a category!
Not sure how to pick apart the topics currently in UX which likely would want to go into Bug or Feature. Might be a good exercise to go through and clean that all up.
4 个赞
Some thoughts from my side:
- I believe that dividing over 3000 topics into just 2 categories is a lot of work, and I wonder who will have the time to take on this task.
- Furthermore, I do not believe that all topics in UX can be easily divided into Feature and Bug. For me, a report about a text that cannot be translated is not really a bug report[1]. Likewise, pointing out an incomprehensible or outdated text is neither a feature request nor a bug report[2]. Similarly, descriptions of user experiences that contain neither an error nor a concrete improvement suggestion do not fit into Feature or Bug[3].
- I do not know how you have handled this so far, but I had the impression that developers, when necessary, also worked on UX topics, and vice versa. I wonder whether it might be possible to keep things as they were, with the group monitoring the category simply informing the other group if needed, without moving the post. However, I cannot fully evaluate this, as I do not know the processes before or now.
5 个赞
Thanks Moin! You make some good points. I was looking at the total number of UX topics too and it is alot! 
Maybe the issue we’re having is that the UX category is inadequately described and so people are posting things there that should be in Bug or Feature. Here’s how we describe it in our internal documentation.
The UX category is a bit of a halfway house between Feature and Bug. Generally minor display issues would go here rather than Bug, and it would be the home for small changes to existing features. More ‘quality of life’ topics than anything big.
Generally, handling these topics would follow the pattern of the Feature category - About the feature category
Tagging
hmmm this one I would classify as bug… from a pure practical point, but is triaged much more frequently by myself cause UX attracts more vague things.
In this case that badge problem looks like a translation bug to me.
Actually also feels like a bug to me, nothing is open to interpretation here, our text is plainly wrong and needs updating.
This though is very much in the theme of UX to me, it is an open discussion about a pain point without any concrete recommendations yet. It is giving us a story, and place to extract particular bug/feature topics from in future.
Maybe all we need here is to better clarify the rules, leave UX for open unstructured discussion and user stories and keep “clear flaws” in bug … and “clear wish lists” in feature.
I get that everything is very grey in this world though, it is hard to pull a magic wand and fix everything.
Being clearer about our expectations though will help for sure.
7 个赞
You guys are bypassing users now. We can`t (and will not) know how a company assigns or classifies things. It is totally internal thing. All what we can do is guess if something is a bug, UX issue or something totally different. And moderators and staff do theirs magic after that, as is planned in very core of Discourse.
So is this topic actually for staff and power users, and we other mortals can stop follow this, or is someone really thinking that i.e. I, who can’t know differense between an image and an image depending is something happening in file or container level, has ability wonder what position inside CDCK will take care of an issue?
In more general level here is two aspects, at least (as everyone knows):
- categories aren’t logical boxes where are strict limits
- for which users are categorien made to, public or internal
I don’t know… I’ve followed policy where I use
- support if I don’t know if the issue is me,
- UX if I have feeling, that something is planned to work such way
- bug if something stopped work or breaks places totally
But I will never choose a category depending who in which position will try to take care of it. It is purely a managerial question.
2 个赞
I like the idea of ux as a tag (and maybe have dev as a tag too?) , but I agree that there could be UX cases that feel like they don’t really belong in a different category either.
And some topics may be technically a feature, but are so small, that they would feel out of place in the feature category to vote on, for example: Clickable components instead of just the Edit button
But maybe we shouldn’t care? And any issue that asks to change something does belong in the feature category, no matter how small?
Or maybe we should have a category “Suggestions” – for things that aren’t broken, aren’t a full-blown feature request, and aren’t about how to do things. And then we can tag it dev or ux internally.
Edit: realised we already have a ux-tag, it’s just under utilised atm
4 个赞
A Suggestions category seems important. I have it on my 2 communities.
Sometimes a tag can be overlooked or the UX category may not be as clear to certain users, but a Suggestions category is pretty clear about what it is for.
1 个赞
I really don’t think we need to change much about categories here, they’ve been working fine for a while and mis-categorization happens, but not at any burdensome rate from what I can see. If mentions, tags, and assigns aren’t doing the trick for internal triage it feels like something’s going wrong… because we have a lot of options there.
1 个赞
Digging deep, I am not sure @moin 
I think the core of the problem here is:
- Sam recategorizes something from UX → Bug
- Sam knows how touching anything about anyone’s post can make them feel bad, or feel like they made a mistake
- Sam apologizes
- Then users get confused, want to self-correct, and there is a painful cycle.
Maybe the root problem here is?
Sam should feel free to recategorize as he sees fit, to better meet our business needs, and should not be apologizing about stuff every time he does that?
1 个赞