안녕하세요, 이는 동등한 것이 아니며, 위에서도 많은 예시를 드렸습니다.
어쨌든 이 옵션을 되돌리지 않겠다는 명확한 입장을 밝혀주시는 것이 공평할 것입니다.
관리자 또는 커뮤니티 관리자 중 수십 명이 여전히 기다리고 있다고 생각합니다.
익명 사용자에도 해당됩니다.
이번 논란은 사이트가 특정 수준의 정밀도(fidelity)를 요구하는 것에 관한 것입니다.
그들은 최신 주제 목록이 딱 원하는 대로 보이길 원하며, 최종 사용자가 그 ‘딱 원하는 대로’ 보이는 방식을 제어할 수 없기를 원합니다.
@Heather_Dudley / @ClawdiaWolf의 경우, 이는 최종 사용자에게 문제가 될 수 있습니다. 홈 페이지에서 모든 ‘지역’ 카테고리가 억제되었기 때문입니다. 지역이 400개나 되어 화면이 어지러워 보일 수 있기 때문이죠.
그런데 Sydney라는 사용자는 왜 홈 페이지에서 Sydney 관련 주제를 볼 수 없어야 합니까?
이 문제를 해결하기 위해, 우리는 이제 사이트가 기본적으로 모든 항목이 음소거(muted)된 모드로 작동하도록 허용합니다. 관리자는 ‘기본 표시’ 카테고리를 선택할 수 있으며, 이는 향후 유지보수를 훨씬 쉽게 만들어 줍니다. 카테고리를 추가할 때 아무 조치도 필요하지 않고, 사용자가 원한다면 여전히 Sydney를 팔로우할 수 있습니다.
결국 이 논의가 도달할 곳은, 최신 주제 목록에 절대, 절대, 절대, 절대 표시되지 말아야 할 주제에 대해 위에서 아래로 강력한 지시를 원하는 사람들을 위해 플러그인 훅(hook)을 제공하는 것이 될 것입니다.
그 말은 우리 외국어 섹션을 복구할 방법이 없다는 뜻인가요?
해당 카테고리들은 현재 “카테고리” 페이지에서 숨겨져 있으며, 외국어 게시글들은 “최신” 섹션에 표시되고 있습니다. “최신” 섹션은 영어 게시글만 표시되도록 되어 있어야 합니다. 외국어 섹션에 대한 알림을 더 이상 받지 못하는 것인지도 확실하지 않습니다.
부모 카테고리인 비영어(Non-English) 카테고리에 들어가도(사용자가 발견하기 어려운 것 같습니다) 언어 하위 카테고리 중 네덜란드어(Nederlands) 하나만 나열되어 있고, 나머지 언어 카테고리들은 사라져 있습니다.
이상하게도, 언어 카테고리 중 하나에 게시글을 작성하면 해당 게시글은 여전히 /latest에 표시되는데, 카테고리 페이지 자체는 사라진 상태입니다.
게시글을 음소거(mute)하지 않고도 메인 페이지에서 제외할 방법이 아직 남아 있을까요?
여전히 이해가 잘 안 됩니다.
예를 들어 "French"를 기본 음소거 대상으로 설정한다고 가정해 보겠습니다.
- “French” 게시물은 익명 사용자와 모든 사용자에게 프론트 페이지에 표시되지 않습니다.
- “French” 사용자는 사용자 설정에서 이를 음소거 해제하여 프론트 페이지에서 해당 카테고리를 계속 볼 수 있습니다.
현재 보고 있는 사이트에서 내가 발견한 유일한 문제는, 설정에서 해당 항목을 찾지 않는 한 프랑스어 카테고리를 음소거 해제할 수 있다는 사실을 알 수 없다는 점입니다. 또는 프랑스어 카테고리로 연결되는 주제(또는 헤더 링크, 또는 유사한 요소)가 있어야 할 것입니다.
죄송합니다. 변경 사항이 무엇을 했는지 조금 혼란스럽습니다. 이전에는 /categories 페이지에 외국어 카테고리 목록이 있었는데, 이제 그 카테고리들이 사라졌고, 어떻게 하면 그 목록에 다시 표시할 수 있는지 모르겠습니다. 다만, 해당 카테고리의 게시물이 /latest에 표시되지는 않아야 합니다. "latest"는 영어 게시물에만 해당하기 때문입니다.
음 …
"음소거된 카테고리를 카테고리 목록에서 숨기기"라는 사용자 설정을 추가하는 건 어떨까요? 기본값은 꺼져 있는 상태로요. 그런 식으로요.
그러면 시스템에 익숙해지면 그때 켜면 되니까요.
이렇게 하면 새로운 변경 사항에 대한 불만을 100% 해결할 수 있을까요?
뭔가 이상합니다. 관리자 계정으로 상위 카테고리(/c/non-english)에 접속하면 ‘Nederlands’(네덜란드어) 카테고리(카테고리 중 가장 최근에 추가된 것)만 보입니다. 관리자 계정으로 /categories에 접속하면 비영어권(Non-English) 카테고리가 없습니다.
테스트 계정(TL0)으로 로그인하면 /categories와 /c/non-english 페이지에서 9개 비영어권 카테고리를 모두 볼 수 있습니다.
비영어권 카테고리에 작성한 테스트 게시글은 영어 전용이어야 할 /latest 페이지로 이동합니다.
수정: 관리자 계정과 TL0 사용자 모두 게시글을 작성한 후 해당 주제가 “watching”(관심) 상태로 설정됩니다. “muted”(음소거) 상태는 보이지 않습니다.
이해가 잘 안 됩니다.
카테고리 음소거는 기본 상태를 지정하는 것입니다. 해당 카테고리의 모든 주제는 사용자가 카테고리의 기본 상태를 덮어써서 여전히 추적하고 감시할 수 있습니다.
아니요. 사용자가 상호작용을 하면 특정 주제들이 여전히 /latest로 다시 나타나기 때문입니다.
기존 방식에서는 사이트 운영자가 필요하다고 판단하는 곳에 파티션을 설정할 수 있었습니다. 음소거(Muting) 기능은 이미 존재했지만, 위의 게시물들이 보여 주듯 훨씬 더 복잡했습니다.
예전에는 '이 카테고리를 latest에서 억제’라는 기능이 있었는데, 이제는 다음과 같이 나뉘게 됩니다:
- 음소거를 위한 카테고리 설정
- 음소거를 위한 사용자 설정
- 가시성을 위한 사용자 설정
원래 동작 방식을 완전히 재현하려면, 음소거된 카테고리의 게시물이 latest로 다시 유입되는 것을 막기 위한 추가 설정이 필요합니다. 왜냐하면 일부 사이트 운영자에게는 이것이 유리한 사용 사례가 있기 때문입니다.
저는 이 문제로 인해 진행 중인 프로젝트를 곧 보류하게 될 것입니다. 클라이언트는 내부 협업용으로 Discourse를 사용하길 원했는데, 아직 발표되지 않은 제목에 대한 논의나 ‘오프토ピック’ 사항이 포함된 특정 카테고리를 억제하고 싶었습니다. 그들은 'latest에서 억제’가 제공했던 동작 방식을 좋아했습니다. 왜냐하면 스태프가 해당 카테고리 내 주제에 참여하더라도 주제 제목이 /(즉, latest)에 표시되지 않아, 해당 카테고리를 직접 찾아봐야 했기 때문입니다. 당분간 제 제안은 동일한 격리를 위해 별도의 2차 인스턴스를 사용하라는 것입니다.
카테고리의 기본 상태는 특정 카테고리에서 시작된 주제에 대한 기본 상태를 의미하며, 사용자가 상호작용할 때 이 상태를 재정의할 수 있습니다. 위 모든 설명의 전제는 이 동작 방식이 항상 바람직하다는 것이지만, 다목적 인스턴스를 살펴보면 그렇지 않은 것으로 보입니다.
이 부분에 대해서는 근본적으로 동의하지 않습니다. 사용자가 특정 주제를 명시적으로 추적하거나 감시(watching)하고 있다면, 해당 주제에 실제로 관심이 있으며 최신 목록에 표시되기를 원한다는 매우 강한 신호를 보내는 것입니다. 최신 목록에 표시하고 싶지 않다면 언제든지 다시 일반 상태로 되돌리면 되지 않나요?
이 부분은 이해가 되지 않습니다.
제가 여기서 제안하는 것은 다음과 같은 사용자 옵션입니다.
“음소거된 카테고리에 정말로, 절대, 관심이 없으며 그 내용을 절대 보고 싶지 않다” (예: “정말로, 정말로 정치가 싫다”)
vs
“보통은 음소거된 카테고리에 관심이 없지만 가끔은 둘러보고 싶기도 하므로, 드롭다운 메뉴와 카테고리 목록에는 계속 남겨두길 원한다”
조용히 설정된(muted) 카테고리에서 토픽을 자동으로 추적하지 않도록 수정하는 것이 더 단순하고 일관된 해결책이 아닌가요? 저에게는 더 나은 기본값으로 보입니다.
결국 모두가 이미 사용하던 동일한 기능을 만들게 되지만, 다섯 개나 여섯 개의 다른 설정 뒤에 접근을 숨기는 결과를 낳습니다. 비유하자면, 디스커스의 코나미 코드 같은 것이죠.
해당 설정들의 동작 방식이 언젠가 개편되면, 게시물이 보여서는 안 되는 곳에 나타나기 시작할 때 우리는 다시 이 자리로 돌아올 것입니다.
결국, 최신 목록에서 게시물을 숨기는 접근을 사이트 설정 하나로 잠그는 것보다 이것이 정말로 더 간단한가요?
개인적으로는 플러그인에서 "이상하고도 멋진 모험을 떠나고 싶다"는 식의 기능을 구현하는 쪽을 훨씬 선호합니다.
본질적으로 사용자는 ‘최근’ 탭에서 무엇을 보고 무엇을 보지 않을지 선택할 권리가 있습니다. 사용자가 제어권을 잃는 이상한 분할을 허용하는 설정은 플러그인의 영역이라고 생각합니다.
솔직히 말해서, 정말로 이 기능이 절실히 필요한 극소수의 사이트를 위해 기존 기능을 복원하는 플러그인을 만들어볼 의향은 있지만, 이런 반사용자(anti-user) 기능을 코어에 포함하는 것은 불안하게 느껴집니다.
매우 선택적인 시각입니다. 직원이 협업할 수 있는 환경을 제공하기를 원하며, 제한적인 ‘업무 외’ 카테고리를 허용하는 것을 고려 중인 고용주라면 이러한 기능은 매우 바람직할 수 있습니다.
사용자 비우호적일 가능성이 있지만, 잘못 설정될 경우 커뮤니티에 파괴적 영향을 미칠 수 있는 것들은 많습니다.
다시 인사드립니다.
여기서 우리가(아직도 "suppress option(카테고리 억제 옵션)"을 지지하는 사람들) 설명하고자 하는 핵심은 다음과 같습니다.
“저는 사이트 운영자로서 특정 카테고리의 게시물이 /latest(최신 목록)에 나타나지 않도록 동작을 제어하고 싶습니다”
이는 여전히 “muted categories(음소거된 카테고리)” 기능과는 완전히 별개의 문제라고 생각합니다.
“muted categories” 기능에 관해서는 그것이 실현 가능한(DWIM) 옵션이라고 생각합니다. 그러나 그럼에도 불구하고, 우리 중 일부에게는 “suppress category(카테고리 억제)” 요구사항을 해결하지는 못합니다.
그것은 정말 훌륭할 것입니다. 만약 그 기능을 Discourse 코어 내에 유지하는 것이 아예 불가능하다면, 전용 플러그인으로 구현하는 것이 우리에게 세상을 구해 줄 것입니다.
“suppress category” 기능의 제거가 더 많은 사람들에게 영향을 미칠 때, 그와 병렬로 또는 조만간 이 작업을 진행할 가능성이 있을까요?
경청해 주셔서 다시 한번 감사드리며,
친구 같은 인사 드립니다,
안드레아스.
이건 “정의상” 유저에게 불리한 것 아닌가요? “여러분은 다 아이들이다. 최소한의 자제력조차 믿을 수 없다. 이런 종류의 토론을 하고 싶다면 여기로 가라 
” 라고 말하는 거잖아요.
이 카테고리를 음소거 해제해 드리고 싶지 않아요. 제가 만든 그 감옥 안에서만 볼 수 있을 테니까요.
저는 이를 타협이라고 생각합니다.
고용주는 그러한 공간을 마련할 의무가 없습니다. 새로운 도구의 도입을 촉진한다는 점이 명백한 이점이지만, 이러한 부가 가치가 본래의 목적을 압도하지 않도록 해야 합니다.
직장 환경에서는 사이드바 테마 같은 요소가 보통 매우 잘 작동하기 때문에, 이런 종류의 타협은 금방 힘을 잃게 됩니다. 그리고 사이드바는 그런 기능과 거의 직교적인 관계에 있죠. 사이드바를 사용하면 어차피 ‘최근’ 탭에 머무는 시간이 훨씬 줄어들게 됩니다.
결국 기존 기능을 플러그인으로 제공하는 쪽으로 마음을 굳혀가고 있습니다.
다시 한번, 이 의견에 +1입니다!
저는 여러분의 의견을 충분히 이해하며, 여러분의 관점을 인정합니다. “음소거 카테고리(muted category)” 기능을 사용하면 사용자가 /latest에서 무엇을 볼지 스스로 통제할 수 있으므로 더 많은 자유를 줄 수 있습니다. 그러나 “카테고리 억제(suppress category)” 기능이 검열에 관한 것은 결코 아니라는 점을 명확히 하고 싶습니다. 적어도 우리의 관점에서는 그렇습니다.
오히려 우리는 “카테고리 억제” 기능을 модератор(운영진)로서, 간헐적이든 영구적이든 높은 트래픽을 가진 카테고리에서 오는 노이즈를 줄여 모든 사용자(익명 및 로그인 사용자)의 /latest 화면이 지저분해지는 것을 방지하는 수단으로 보고 사용하고 있습니다.
또 다른 예를 들자면, GitHub - huw/github-to-discourse: Forwards commit data from a GitHub webhook to a Discourse thread · GitHub 같은 도구를 사용할 때 특정 카테고리로 자동 게시되는 포스트가 있을 수 있습니다. 이러한 도구에서 생성된 포스트는 원래 토론 포럼이라는 Discourse의 사용 사례를 넘어선 특정 맥락에서는 "실제 토론"이 전혀 아닙니다.
이것이 일부 희귀한 사이트에 해당할지 여부는 제가 상상하기 어려운 부분입니다. 따라서 관점을 다음과 같이 수정해 보겠습니다. 일부 사이트는 특정 기능 세트나 요구 사항을 실행하는 데 있어 이것이 핵심적인 기능일 수 있다.
따라서 이러한 종류의 특정 사이트의 요구를 충족시키기 위해 이 기능을 플러그인으로 제공한다면, 이 옵션을 유지하자는 논의를 하고 있는 모든 사람에게 완전히 괜찮은 해결책이 될 것입니다.