누가 가장 수정할 가능성이 높은지"에 따라 카테고리를 선택하는 것은 조금 이상하게 느껴집니다. 글로벌 display: none 때문에 포럼이 비어 있는 경우도 디자이너가 수정할 것이므로 버그가 아니라고 말씀하시겠습니까?
물론 "중요하지 않으니까 하나를 선택하세요, 나중에 이동할 수 있습니다"라고 말씀하실 수 있지만, 이는 게시할 때만 도움이 됩니다. 이전 보고서를 찾으려고 할 때 저는 이 두 가지 문제를 모두 #contribute:ux에서 검색할 것입니다. 수정 책임을 카테고리에서 독립적으로 추적할 수 있는 방법이 있을까요?
10개의 좋아요
동의합니다. 이건 정말 더 혼란스럽고, 운영진 입장에서 여기서 무엇을 해야 하는지 파악하기가 매우 어렵습니다.
@tobiaseigen / @jordan.vidrine 이 문제에 대해 어떤 생각이 있으신가요?
@Moin 이 부분이 더 잘 작동할 수 있는 방법에 대한 제안이 있으신가요?
한 가지 대안은 기능/버그를 무조건적으로 해당 카테고리에 배치하고, UX를 나타내기 위해 태그를 사용하는 것입니다.
분명히 어려운 문제입니다.
4개의 좋아요
저에게 이는 좋은 해결책으로 보입니다. 어떤 카테고리에 게시해야 하는지 명확하며, UX에 관심이 있는 사용자는 해당 태그를 관찰할 수 있습니다. 또 다른 장점은 카테고리를 하나 없앨 수 있다는 것입니다.
현재 #contribute:ux에 있는 주제들을 어떻게 분류할지 확실하지 않습니다. 이 주제들은 아마도 Contribute > Bug 또는 #contribute:feature로 이동해야 할 것입니다. 전체를 검토하여 정리하는 것이 좋은 연습이 될 것 같습니다.
4개의 좋아요
제 생각은 다음과 같습니다:
- 3,000개 이상의 주제를 단 두 개의 카테고리로 나누는 것은 상당한 작업일 것 같고, 이 작업을 맡을 시간이 있는 사람이 누구일지 궁금합니다.
- 또한 UX 카테고리의 모든 주제를 쉽게 기능(FEATURE)과 버그(BUG)로 나눌 수 있다고 생각하지 않습니다. 예를 들어, 번역이 불가능한 텍스트에 대한 보고서는 엄밀히 말해 버그 보고서는 아닙니다[1]. 마찬가지로, 이해하기 어렵거나 오래된 텍스트를 지적하는 것은 기능 요청이든 버그 보고서는 아닙니다[2]. 또한, 오류나 구체적인 개선 제안이 모두 없는 사용자 경험에 대한 설명 역시 기능이나 버그 카테고리에 적합하지 않습니다[3].
- 그동안 어떻게 처리해 왔는지는 정확히 알지 못하지만, 필요할 때 개발자들도 UX 주제에 참여하고, 그 반대 경우도 있었다는 인상을 받았습니다. 게시물을 이동시키지 않고, 해당 카테고리를 모니터링하는 그룹이 필요할 때 다른 그룹에게만 알리는 방식으로 이전과 같은 상태를 유지할 수 있을지 궁금합니다. 다만 이전과 현재의 프로세스를 완전히 파악하지 못하고 있어 이 부분을 온전히 평가하기는 어렵습니다.
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를 적용할 수 있습니다
음, 이건 버그라고 분류하고 싶네요… 순수한 실용적인 관점에서 말입니다. 하지만 UX는 더 모호한 것들을 더 많이 끌어들이기 때문에 제가 훨씬 더 자주 분류(triage)하곤 합니다.
이 경우 그 배지 문제는 제게 번역 버그처럼 보입니다.
실제로 이것도 제게는 버그처럼 느껴집니다. 여기서 해석의 여지는 전혀 없으며, 우리의 텍스트가 명백히 잘못되었고 업데이트가 필요합니다.
이것은 제게 매우 UX의 주제에 해당합니다. 아직 구체적인 권장 사항이 없는 페인 포인트(고통의 지점)에 대한 열린 토론입니다. 우리에게 이야기를 제공하며, 미래에 구체적인 버그/기능 주제를 추출할 장소를 마련해 줍니다.
아마도 여기서 필요한 것은 규칙을 더 명확히 하는 것뿐일 수 있습니다. UX는 열린 비구조화된 토론과 사용자 스토리를 위해 남겨두고, "명백한 결함"은 버그에, "명백한 희망 목록"은 기능에 유지하는 것입니다.
이 세상에서 모든 것이 매우 회색 지대(gray area)라는 점은 이해합니다. 마법 지팡이를一挥(일회)로 모든 것을 고치기는 어렵죠.
하지만 우리의 기대치를 더 명확하게 하는 것은 확실히 도움이 될 것입니다.
7개의 좋아요
여러분은 이제 사용자를 우회하고 있습니다. 우리는 (그리고 앞으로도) 어떤 회사가 무엇을 어떻게 할당하거나 분류하는지 알 수 없고, 알 수도 없습니다. 이는 완전히 내부적인 문제입니다. 우리가 할 수 있는 것은 그것이 버그인지, UX 문제인지, 아니면 전혀 다른 무언지 추측하는 것뿐입니다. 그리고 그 후, 디스코스의 핵심 구조에 계획된 대로 모더레이터와 스태프가 마법을 부리는 것입니다.
그러면 이 토픽은 실제로 스태프와 파워 유저들을 위한 것이며, 우리 같은 평범한 사람들은 더 이상 이 토픽을 팔로우하지 않아도 되는 건가요? 아니면 누군가 정말로, 파일 레벨인지 컨테이너 레벨인지에 따라 이미지가 다른지조차 구분할 수 없는 제가 CDCK 내에서 어떤 직급의 사람이 이 문제를 처리할지 궁금해할 능력이 있다고 생각하는 건가요?
더 일반적인 수준에서 말하자면, (모두가 아는 것처럼) 최소한 두 가지 측면이 있습니다:
- 카테고리는 엄격한 한계가 있는 논리적 상자가 아닙니다.
- 카테고리는 공개적으로 사용자를 위해 만들어졌나요, 아니면 내부적으로 사용자를 위해 만들어졌나요?
모르겠습니다… 저는 제가 사용하는 정책에 따라 다음과 같이 선택해 왔습니다:
- 문제가 내 실수인지 모르겠을 때: 지원(Support)
- 무언가가 그렇게 작동하도록 계획된 것 같은 느낌이 들 때: UX
- 무언가가 작동이 멈추거나 완전히 깨졌을 때: 버그(Bug)
하지만 어떤 직급의 사람이 그 문제를 처리하려 할지에 따라 카테고리를 선택하는 일은 절대 하지 않을 것입니다. 그것은 순수하게 관리적인 문제입니다.
2개의 좋아요
ux를 태그로 사용하는 아이디어를 좋아합니다(그리고 dev도 태그로 사용하는 것도요?). 하지만 UX 관련 사례 중에는 다른 카테고리에 속한다고 느끼기 어려운 것들이 있을 수 있다는 점에는 동의합니다.
그리고 어떤 주제들은 기술적으로는 기능(feature)이지만, 너무 작아서 기능 카테고리에서 투표 대상으로 다루기에는 어색하게 느껴질 수 있습니다. 예를 들어: Clickable components instead of just the Edit button
하지만 우리가 신경 쓸 필요가 없는 것일까요? 그리고 무언가를 변경해 달라고 요청하는 모든 이슈는 크기에 관계없이 기능 카테고리에 속하는 것일까요?
아니면 "제안(Suggestions)"이라는 카테고리를 두는 것이 어떨까요? 고장 난 것도 아니고, 완전한 기능 요청도 아니며, 어떻게 하는지에 관한 것도 아닌 것들을 위한 카테고리가요. 그리고 내부적으로 dev 또는 ux 태그를 붙일 수 있습니다.
수정: 이미 ux 태그가 있다는 것을 깨달았지만, 현재는 거의 사용되지 않고 있습니다.
4개의 좋아요
Suggestions 카테고리가 중요해 보입니다. 제 커뮤니티 2곳에 이 카테고리가 있습니다.
때로는 태그가 놓치거나, Contribute > UX 카테고리가 일부 사용자에게는 명확하지 않을 수 있지만, Suggestions 카테고리는 그 용도가 매우 명확합니다.
1개의 좋아요
카테고리 부분은 크게 바꿀 필요가 없다고 생각합니다. 이미 꽤 오랫동안 잘 작동해 왔고, 분류 오류는 발생하지만 제가 보기에는 부담스러운 수준은 아니거든요. 내부 분류(triage)에 멘션, 태그, 담당자 지정이 제대로 역할을 하지 않는다면 뭔가 잘못되고 있는 것 같습니다… 그쪽에는 선택지가 꽤 많거든요.
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 카테고리 설명을 어떻게 개선할 것인가요?
좋은 질문입니다. 저는 다음과 같이 말하겠습니다.
UX 토픽은 제품이 기술적으로 의도한 대로 작동하지만, 디자인, 상호작용 또는 플로우가 사용자에게 불필요한 마찰, 혼란 또는 비효율성을 초래할 때 사용됩니다.
다음 내용이 포함된 것도 좋습니다:
하지만 실제로 깨져 있는 것, 아무리 작더라도,은 ux 태그가 달린 버그로 처리하는 것이 맞다고 생각합니다.
3개의 좋아요
새로운 Contribute > UX 설명으로 이 정도면 어떨까요? 약간 어색한 느낌이 들지만 더 간결해졌어요. 괜찮지 않을까요? (카테고리 배너에 태그 아이콘이 표시되지 않는 문제를 제보하기 위해 Contribute > UX 토픽을 하나 올렸어요)
원문:
Discourse의 사용자 인터페이스와 기능 제시 방식(언어 및 UI 요소 포함)에 대한 논의.
현재:
Discourse 사용자 인터페이스의 사소한 표시 문제와 기존 기능에 대한 작은 변경 사항, 그리고 기능 제시 방식(언어 및 UI 요소 포함)에 대한 논의. 큰 기능보다는 ‘사용 편의성’ 관련 토픽이 더 많습니다.
제안:
UX 토픽은 Discourse가 기술적으로 의도대로 작동하지만, 디자인, 상호작용 또는 플로우가 사용자에게 불필요한 마찰, 혼란 또는 비효율을 유발할 때 사용합니다. 또한 작은 “사용 편의성” 개선 사항도 여기에 포함됩니다. 토픽의 성격에 따라 completed 또는 fixed 태그가 적용됩니다.
1개의 좋아요
고마워요, 괜찮네요 
좋아요! 변경했습니다.
(참고: 설명 변경 사항이 카테고리 배너에 반영되는 데 몇 분 정도 걸리는 게 정말 이상해요. 하드 리프레시를 해도 안 되더라고요.)
2개의 좋아요