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 likes
Ik ben het met je eens, dit is extra verwarrend, het is erg moeilijk voor operators om hier te weten wat ze moeten doen.
@tobiaseigen / @jordan.vidrine hebben jullie gedachten over dit probleem.
@Moin suggesties over hoe dit beter zou kunnen werken?
Ik denk dat een alternatief is om dingen gewoon onvoorwaardelijk in feature/bug te laten leven en tags te gebruiken om ux aan te duiden.
Het is zeker een lastige.
4 likes
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 likes
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 likes
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 likes
Jullie omzeilen nu gebruikers. Wij kunnen niet (en zullen niet) weten hoe een bedrijf dingen toewijst of classificeert. Het is een volledig interne zaak. Het enige wat we kunnen doen, is gokken of iets een bug, een UX-probleem of iets heel anders is. En moderators en medewerkers doen daarna hun magie, zoals gepland in de kern van Discourse.
Is dit onderwerp dus eigenlijk voor medewerkers en power users, en kunnen wij andere stervelingen stoppen met volgen, of denkt iemand echt dat ik, die het verschil niet kan weten tussen een afbeelding en een afbeelding, afhankelijk van of er iets gebeurt op bestands- of containerniveau, kan bedenken welke functie binnen CDCK een probleem zal aanpakken?
Op een algemener niveau zijn er minstens twee aspecten (zoals iedereen weet):
- categorieën zijn geen logische bakken met strikte grenzen
- voor welke gebruikers zijn categorieën gemaakt, publiek of intern
Ik weet het niet… Ik heb het beleid gevolgd waarbij ik gebruik maak van
- support als ik niet weet of het probleem bij mij ligt,
- UX als ik het gevoel heb dat iets zo gepland is om te werken
- bug als iets stopt met werken of plekken volledig breekt
Maar ik zal nooit een categorie kiezen op basis van wie in welke functie zal proberen ervoor te zorgen. Het is puur een managementkwestie.
2 likes
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 likes
Een categorie Suggesties lijkt belangrijk. Ik heb het op mijn 2 communities.
Soms kan een tag over het hoofd worden gezien of is de #ux-categorie voor bepaalde gebruikers misschien niet zo duidelijk, maar een categorie Suggesties is vrij duidelijk waarvoor deze bedoeld is.
1 like
Ik denk niet dat we hier veel aan de categorieën hoeven te veranderen, ze werken al een tijdje prima en verkeerde categorisatie gebeurt, maar niet in een hinderlijk tempo voor zover ik kan zien. Als vermeldingen, tags en toewijzingen niet helpen bij de interne triage, voelt het alsof er iets misgaat… omdat we daar veel opties hebben.
2 likes
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?
2 likes
I’ve been thinking about this topic for the last several weeks as I participate in discussions, address topics in the UX Bug Feature categories, and create topics of my own.
I think this is definitely the case. Sam and members of the team are free to categorize and tag topics as they see fit, in the interest of responding to the topic and getting to a resolution. If members are confused about these decisions, they can reach out to @moderators.
This is a great example of a topic that belongs in UX. It is small and is specifically about making an improvement to the interface. It’s also a great example of the kind of collaboration between community members and the team that we like to see, that leads to very nice quality of life improvements. 
Continuing on with the example Charlie cited, an area our team team needs to work on is pursuing topics like this to the end so they can be closed. Even this quite excellent collaboration was left with some loose ends. This is natural in the ebb and flow of discussion and collaboration here, and our engineer and designers are busy. As a result UX enhancements sometimes fall between the cracks, no matter how good the suggestion or how small the request feels. After a while @moderators can help identify these and shephard them home.
I updated the description for the UX category to make public what has been our internal approach to this category. This I hope will help everyone understand better what goes in UX vs other categories Feature and Bug.
Discussion about minor display issues and small changes in the Discourse user interface, and how features are presented (including language and UI elements). More ‘quality of life’ topics than anything big.
completed or fixed tags are applied to topics in this category depending on the nature of the topic.
Let me know if this is not clear enough or if you can think of further refinements. I’d like to give Bug and Feature the same treatment but will hold off on that for the minute.
Ik denk dat we de tag ‘ux’ ook vaker moeten gebruiken. Het zou naar mijn mening helpen bij het triageren, iets kan een ondersteunings- of bugonderwerp zijn, maar heeft betrekking op UX. Dit zou ook de twijfel oplossen van “dit is een bug, maar het is iets visueels, moet het in Bug of in UX”.
=> maak er een bug van, maar plaats er een ux tag op
Ik denk dat de #ux-categorie voornamelijk suggesties voor verbeteringen moet bevatten, dingen die onduidelijk zijn. Niet dingen die kapot zijn.
Die onderscheiding lijkt mij tenminste logisch.
3 likes
Eens met het meer gebruiken van de ux tag, in alle drie de categorieën! Mensen die veel om ux geven, kunnen die tag dan volgen.
Het lijkt erop dat we nog niet helemaal op één lijn zitten - naar mijn mening kan UX zowel bugs als functieaanvragen bevatten, maar het moeten kleine “quality of life”-verbeteringen zijn en niets groots. Als iets echt kapot is in de UI, dan komt het in Bug. Als het een grootschalig project is (bijv. het bewerken van de meta-beschrijving van een tag toestaan), dan komt het in Feature.
Hoe zou je de beschrijving van de #ux-categorie verbeteren om overeen te komen met jouw begrip van zaken?
Good question. I would say something like…
A UX topic is used for when the product technically works as intended, but the design, interaction, or flow creates unnecessary friction, confusion, or inefficiency for users.
I’m also good with it containing:
But I think anything that’s actually broken, even if small, should just be a bug with a ux tag.
3 likes
How about this for a new UX description? Feels a little stilted but tighter. I think it works? (I posted a UX topic of my own to report that tags don’t display properly in category banners)
Original:
Discussion about the user interface of Discourse and how features are presented (including language and UI elements).
Current:
Discussion about minor display issues and small changes to existing features in the Discourse user interface, and how features are presented (including language and UI elements). More ‘quality of life’ topics than anything big.
completed or fixed tags are applied to topics in this category depending on the nature of the topic.
Suggested new:
UX topics are used for when Discourse technically works as intended, but the design, interaction, or flow creates unnecessary friction, confusion, or inefficiency for users. Also for small “quality of life” improvements. completed or fixed tags are applied depending on the nature of the topic.
1 like
Thanks, sounds good to me 
Cool! Ik heb de wijziging doorgevoerd.
(terzijde: het is zo vreemd dat wijzigingen aan de beschrijving een paar minuten nodig hebben om zichtbaar te worden in de categoriebanner. zelfs een harde vernieuwing doet het niet.)
2 likes