누가 가장 수정할 가능성이 높은지"에 따라 카테고리를 선택하는 것은 조금 이상하게 느껴집니다. 글로벌 display: none 때문에 포럼이 비어 있는 경우도 디자이너가 수정할 것이므로 버그가 아니라고 말씀하시겠습니까?
물론 "중요하지 않으니까 하나를 선택하세요, 나중에 이동할 수 있습니다"라고 말씀하실 수 있지만, 이는 게시할 때만 도움이 됩니다. 이전 보고서를 찾으려고 할 때 저는 이 두 가지 문제를 모두 #contribute:ux에서 검색할 것입니다. 수정 책임을 카테고리에서 독립적으로 추적할 수 있는 방법이 있을까요?
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개의 좋아요
저에게 이는 좋은 해결책으로 보입니다. 어떤 카테고리에 게시해야 하는지 명확하며, UX에 관심이 있는 사용자는 해당 태그를 관찰할 수 있습니다. 또 다른 장점은 카테고리를 하나 없앨 수 있다는 것입니다.
현재 #contribute:ux에 있는 주제들을 어떻게 분류할지 확실하지 않습니다. 이 주제들은 아마도 Contribute > Bug 또는 #contribute:feature로 이동해야 할 것입니다. 전체를 검토하여 정리하는 것이 좋은 연습이 될 것 같습니다.
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개의 좋아요
Moin, 감사합니다! 좋은 지적을 해주셨네요. 저도 Contribute > UX 토픽의 총 개수를 살펴봤는데, 정말 많네요! 
문제는 Contribute > UX 카테고리가 제대로 설명되어 있지 않아서, #contribute:bug나 #contribute:feature에 올라가야 할 내용들이 그곳에 게시되고 있기 때문인 것 같습니다. 내부 문서에서는 이렇게 설명하고 있습니다.
#ux::category 카테고리는 #feature::category와 #bug::category 사이의 중간 지점과 같습니다. 일반적으로 사소한 표시(display) 문제는 #bug::category 대신 여기에 게시되며, 기존 기능에 대한 작은 변경 사항들의 집합소 역할을 합니다. 큰 것보다는 ‘사용성 향상(QoL)’ 관련 주제들이 주로 올라옵니다.
일반적으로 이 카테고리의 주제 처리 방식은 #feature::category 카테고리의 패턴을 따릅니다 - 기능 카테고리에 대하여
태그 지정
- 중간 지점이라는 테마에 맞춰, 토픽의 성격에 따라 이 카테고리의 주제에 completed 또는 #fixed::tag를 적용할 수 있습니다
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개의 좋아요
Suggestions 카테고리가 중요해 보입니다. 제 커뮤니티 2곳에 이 카테고리가 있습니다.
때로는 태그가 놓치거나, Contribute > UX 카테고리가 일부 사용자에게는 명확하지 않을 수 있지만, Suggestions 카테고리는 그 용도가 매우 명확합니다.
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.
3개의 좋아요
깊이 파고들수록 @moin 님이 어떻게 해야 할지 확신이 서지 않네요 
여기서 핵심 문제는 다음과 같다고 생각합니다:
- Sam이 어떤 내용을 #contribute:ux에서 #contribute:bug로 재분류합니다.
- Sam은 누군가의 게시글에 아무런 수정을 가하는 것만으로도 그 사람이 기분 나빠하거나 실수를 했다고 느낄 수 있다는 것을 잘 알고 있습니다.
- Sam이 사과합니다.
- 그러자 사용자들은 혼란을 느끼고 스스로 수정하려 하며, 고통스러운 악순환이 시작됩니다.
아마도 근본 문제는 이것일까요?
Sam은 비즈니스 니즈를 더 잘 충족시키기 위해 스스로 판단하여 자유롭게 재분류할 수 있어야 하며, 매번 그렇게 할 때마다 사과할 필요는 없지 않을까요?
2개의 좋아요
최근 몇 주간 저는 다양한 토론에 참여하고, Contribute > UX Contribute > Bug Contribute > Feature 카테고리에 속한 주제들을 다루며, 나만의 주제도 생성하면서 이 주제에 대해 고민해 왔습니다.
저도 이것이 분명히 맞는 말이라고 생각합니다. Sam과 팀원들은 주제에 대한 응답과 해결책 도출을 위해 주제와 태그를 자유롭게 분류할 수 있습니다. 이러한 결정에 대해 회원들이 혼란을 느낀다면 @moderators에게 문의할 수 있습니다.
이것은 Contribute > UX 카테고리에 속해야 할 주제의 훌륭한 예시입니다. 이 주제는 작으며, 인터페이스 개선을 구체적으로 다루고 있습니다. 또한 커뮤니티 멤버와 팀 간의 협업이 어떻게 삶의 질(QoL) 향상에 기여하는지를 보여주는 좋은 사례이기도 합니다. 
Charlie가 언급한 예를 이어가자면, 우리 팀이 개선해야 할 영역 중 하나는 이러한 주제들을 끝까지 추궁하여 폐쇄할 수 있도록 하는 것입니다. 이번처럼 훌륭한 협업이었음에도 불구하고 몇 가지 미해결 사항이 남았습니다. 여기의 토론과 협업의 흐름 속에서 이는 자연스러운 일이며, 우리의 엔지니어와 디자이너들은 바쁘기 때문입니다. 그 결과, 제안이 아무리 좋고 요청이 아무리 작아 보여도 UX 개선 사항이 간과되는 경우가 종종 발생합니다. 시간이 지나면 @moderators가 이러한 주제들을 식별하고 마무리를 도와줄 수 있습니다.
저는 Contribute > UX 카테고리의 설명을 업데이트하여, 이 카테고리에 대한 우리의 내부 접근 방식을 공개했습니다. 이를 통해 #contribute:ux에 무엇이 포함되어야 하는지, 그리고 #contribute:feature와 #contribute:bug와 어떻게 다른지 모두가 더 잘 이해할 수 있기를 바랍니다.
경미한 표시 문제와 작은 변경 사항에 대한 토론, 그리고 기능이 어떻게 제시되는지(언어 및 UI 요소를 포함)에 대한 토론. 거대한 것보다는 ‘삶의 질(QoL)’ 관련 주제들이 더 많습니다.
이 설명이 충분히 명확하지 않거나, 추가적인 개선 사항이 생각난다면 알려주세요. #contribute:bug와 #contribute:feature에도 동일한 조치를 취하고 싶지만, 당분간은 보류할 예정입니다.
저도 ‘ux’ 태그를 더 많이 사용해야 한다고 생각합니다. 제 생각에는 이슈 분류(triage)에 도움이 될 것 같습니다. 어떤 문제는 지원 요청이나 버그 주제이면서도 UX와 관련될 수 있으니까요. 이렇게 하면 "이건 버그인데 시각적인 문제라서 #contribute:bug에 올려야 하나, #contribute:ux에 올려야 하나?"라는 고민도 해결됩니다.
=> 버그로 분류하되 ux 태그를 달아두는 방식입니다.
저는 Contribute > UX 카테고리가 주로 개선 제안이나 명확하지 않은 부분에 대해 다루는 곳이어야 한다고 생각합니다. 고장 난 부분에 대해서는 다루지 않는 것이 좋겠습니다.
적어도 저에게는 이런 구분이 합리적으로 느껴집니다.
3개의 좋아요
세 가지 카테고리 모두에서 ux 태그를 더 많이 사용하는 것에 동의합니다! UX에 관심이 많은 사람들이 해당 태그를 지켜볼 수 있게 되니까요.
다만 아직 완전히 의견이 일치하지는 않는 것 같습니다. 제 생각에는 #contribute:ux에는 버그와 기능 요청 모두를 포함할 수 있지만, 반드시 작은 “질적 향상(QoL)” 개선 사항이어야 하며 큰 변경 사항은 포함되면 안 됩니다. UI에서 실제로 깨진 부분이 있다면 #contribute:bug에, 그리고 대규모 프로젝트(예: 태그의 메타 설명 편집 허용)라면 #contribute:feature에 올려야 합니다.
당신의 이해에 맞게 Contribute > UX 카테고리 설명을 어떻게 개선할 것인가요?
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개의 좋아요
새로운 Contribute > UX 설명으로 이 정도면 어떨까요? 약간 어색한 느낌이 들지만 더 간결해졌어요. 괜찮지 않을까요? (카테고리 배너에 태그 아이콘이 표시되지 않는 문제를 제보하기 위해 Contribute > UX 토픽을 하나 올렸어요)
원문:
Discourse의 사용자 인터페이스와 기능 제시 방식(언어 및 UI 요소 포함)에 대한 논의.
현재:
Discourse 사용자 인터페이스의 사소한 표시 문제와 기존 기능에 대한 작은 변경 사항, 그리고 기능 제시 방식(언어 및 UI 요소 포함)에 대한 논의. 큰 기능보다는 ‘사용 편의성’ 관련 토픽이 더 많습니다.
제안:
UX 토픽은 Discourse가 기술적으로 의도대로 작동하지만, 디자인, 상호작용 또는 플로우가 사용자에게 불필요한 마찰, 혼란 또는 비효율을 유발할 때 사용합니다. 또한 작은 “사용 편의성” 개선 사항도 여기에 포함됩니다. 토픽의 성격에 따라 completed 또는 fixed 태그가 적용됩니다.
1개의 좋아요
Thanks, sounds good to me 
Cool! I’ve made the change.
(aside: it’s so weird that changes to the description take a couple minutes to show up in the category banner. even a hard refresh doesn’t do it.)
2개의 좋아요