최근 스레드가 활성화된 채널에서만, 그리고 해당 변경 이후 클라이언트가 아직 새로고침되지 않은 경우에만 이 문제가 나타나요? 아니면 스레드가 활성화된 후 이미 한 번 이상 새로고침을 한 경우에도 나타나요?
이런 비슷한 문제를 얼마 전 발견해 수정한 적이 있었던 것 같습니다.
다시 재발한 걸까요? 지금 tests-passed의 최신 버전으로 업데이트하면 여전히 문제가 나타나요?
2개의 좋아요
모든 채팅 채널이 최근에 활성화되었습니다.
사용자들이 언제, 어떻게 브라우저를 새로고침했는지 정확히 알 수 없습니다. 업데이트가 설치되거나 관리자가 시스템 매개변수를 변경할 때마다 시스템에서 완전한 새로고침을 강제하는 것이 좋은 방법일까요?
귀하의 사용자들에 대해서는 잘 모르겠지만, 저희 사용자의 경우 새로고침을 요청하면 그것이 먹거리인 건지 아닌지 묻는 질문으로 이어질 수 있습니다.
지금 바로 최신 버전으로 설치하고 테스트 사용자들이 지켜보도록 하겠습니다. 회신해 주셔서 감사합니다.
4개의 좋아요
안녕하세요! 댓글에 바로 답장하면 새 스레드가 자동으로 생성된다는 점이 정말 좋습니다 
새로운 댓글은 바로 직전 댓글에 대한 답장이라고 가정하는 방식을 제안합니다. 대화에서 가장 흔한 상황이 바로 그 경우이거든요. 사람들이 대화 중간에 올라온 특정 댓글에 답장할 때는 “답장” 기능을 사용하는 것이 자연스럽지만, 바로 직전 댓글에 답장할 때는 그 기능을 쓰지 않죠. 따라서 사용자가 이 상황에서 타이핑을 시작하는 순간부터 바로 직전 댓글에 답장하여 스레드를 생성하려는 의도라고 가정하면 좋겠습니다. (이 방식은 새 댓글이 추가되더라도 사용자가 삭제하고 다시 쓸 필요가 없습니다.) 즉, 사용자가 타이핑을 시작하면 위에 "(… 에 답장 중)"이라는 문구가 표시되고, 원치 않는 경우 해당 텍스트 바로 옆의 “x” 버튼을 클릭하면 됩니다. 이렇게 하면 프로세스가 더 원활해지고, 제 생각에는 채널을 더 깔끔하게 유지하는 데 도움이 될 것입니다.
4개의 좋아요
채팅 메시지를 CSV 파일로 내보내기
다른 분들도 채팅을 충분히 중요하게 여기고 이를 보존하려는 노력을 하고 있다는 점을 보게 되어 기쁩니다. 이제 채팅을 CSV 형식으로 가져올 수 있게 된 것은 정말 좋은 일입니다. 이 작업을 관리자 설정에서 자동으로 처리할 수 있다면 더욱 좋겠지만, 어쨌든 한 걸음 나아간 것입니다.
"채팅"이라는 개념은 본질적으로 일시적이며 영구적인 저장에 가치가 없는 것으로 여겨져 왔습니다. 아마도 데이터베이스에 "수다"를 포함시키는 부담을 피하려는 의도로 그렇게 본 것이겠죠. 원래의 동기가 무엇이든, 사람들이 채팅 내용을 보존하길 원한다는 점은 명확하며, 관리자가 이를 가능하도록 하는 조치들이 취해지고 있습니다.
이러한 진전에 매우 만족하며, 채팅이 완전히 보존되기를 기대합니다.
4개의 좋아요
말씀을 시작하기에 앞서, 채팅형 커뮤니케이션을 소비하는 누구에게나 다소 상식적인 사실을 인정하고 싶습니다. 바로 채팅은 매우 주관적이며, 수많은 옵션 중 하나를 고르는 경우라면 '정답’을 찾는 것은 사실상 불가능하다는 점입니다.
저는 채팅 스레딩을 두 가지 범주로 나눕니다: 서브스페이스(sub-spaces)와 인라인(inline).
서브스페이스 형식을 따르는 플랫폼은 누군가 메시지를 답글로 달면 '포켓’을 생성하며, 모든 답글은 이 포켓 안에 유지됩니다. 누군가가 클릭하여 참여하지 않는 한 화면에 표시되지 않습니다. 많은 사람들이 Slack에서 이 방식을 익혔을 것이며, 저는 Discourse의 채팅 기능에 내장된 솔루션도 이 범주에 속한다고 분류합니다.
인라인 답글은 모든 응답을 메인 채팅 스레드에 유지하고, 링크/앵커를 통해 이전 메시지를 가리킵니다. 여기에는 두 가지 변형이 있습니다: 인용 텍스트가 있는 경우와 없는 경우입니다. 인용 텍스트가 있는 예로는 Discord(전체 인용이 아닌 발췌문을 사용)나 Apple 기기의 Messages가 있습니다. Discord는 현재 형식으로 전환하기 전에 인용 없는 인라인 답글을 사용했습니다. 인용 없는 인라인 답글의 다른 예로는 Stack Exchange / Stack Overflow의 Chat 기능이 있습니다.
두 방식 모두 유효하며 각자 용도가 있고, 서로가 만드는 문제를 서로가 어느 정도 '해결’하는 경향이 있습니다.
- 저는 서브스페이스 포켓이…
- + 측면적인 사고의 흐름을 포함하거나, 메인 토론에서 벗어나지 않으면서 특정 주제에 대해 깊이 파고들 수 있는 훌륭한 방식이 될 수 있다고 생각합니다.
- + 이러한 분산된 논의를 깔끔하게 유지하여 따라가기 쉽게 하지만,
- - 포켓은 채팅이 이미 다른 주제로 넘어간 후에도 쉽게 놓칠 수 있습니다.
- - 분기된 내용을 봐야 할 사람들을 꼭 태그(ping)하도록 하는 것이 더 중요합니다.
- 인라인 채팅의 경우 반대입니다…
- - 모든 것이 인라인으로 표시되므로, 분산된 논의로 인해 채팅이 어긋나기 쉽습니다.
- - 동시에 여러 가지 논의 흐름을 따라가기 혼란스러울 수 있습니다.
- + 모든 것이 인라인으로 표시되므로, 서브스페이스에서 일어나는 일을 놓칠 일이 없습니다.
- + 사용자가 특정 사람에게 답글을 태그하도록 해야 한다는 점을 크게 고민하지 않아도 됩니다.
수년간 Slack과 Discord를 사용해 온 사용자로서, 저는 '정답’은 아마도 어떤 개발자도 듣고 싶어 하지 않는 것일 거라고 주장합니다. 바로 두 가지를 모두 갖추는 것입니다. 제가 선호하는 방식을 결정하는 가장 큰 요인(제 기준에서)은 다음과 같습니다:
- 채팅에 몇 명의 사람이 관여하는지, 또는 얼마나 바쁜지.
- 한 사람과 채팅 중이거나 활동이 많지 않을 때, 제가 원하는 것은 인라인 답글뿐입니다. 2~3명의 다른 사람과 함께 있어도 서브스페이스는 필요하지 않습니다. 두 사람 사이의 Slack DM에서 서브스페이스를 사용할 때 얼마나 짜증이 났는지 헤아릴 수 없을 정도입니다.
- 많은 참여자가 있고 메시지가 빠르게 오가는 공간에 있으면, 특히 사람들이 답글 기능을 대충 사용할 때, 인라인 대화를 따라가기 훨씬 더 어려워집니다.
- 모든 것을 보고 싶거나 알아야 할 필요가 얼마나 큰지.
- Slack 채널에서 지원 역할을 맡고 있다면, 서브스페이스는 채널을 정리하여 빠르게 훑어볼 수 있게 해줍니다.
- 스레드에 묻혀 있는 것을 놓치면 안 되는 공간에 있다면, 인라인 답글을 선호합니다. FOMO(놓칠까 봐 두려운 마음)는 실재합니다, 친구들이여!
- 스레드가 얼마나 ‘깊어지는지’.
- 질문 뒤에 수십 개 또는 심지어 수백 개의 응답이 따르는 경향이 있는 채널은 서브스페이스여야 합니다.
- 메시지당 응답이 매우 적은 경향이 있는 채널은 보통 인라인으로 작동하는 것이 더 좋습니다.
- 내가 누구인지/무엇에 익숙한지.
- 서브스페이스를 싫어하는 정도가 심해서 이를 제거하는 Slack 스크립트를 만든 사람을 알고 있습니다.
- 팀이 Slack 채널에서 매번 서브스페이스 스레드를 사용해야 한다고 엄격하게 주장하고, 그렇지 않을 때 약간 투덜거리는 사람들을 알고 있습니다.
이 모든 것은 일률적인(또는 대부분에게 맞는) 해결책이 없다는 것을 의미합니다. 저는 다른 Discourse 인스턴스에서 1:1 채팅을 하다가 스레딩 방식의 선택을 보고 놀랐으며, 정말로 스레드를 피할 수 있기를 바랐기 때문에 이 메타 포스트를 찾게 되었습니다.
두 옵션을 모두 제공하기를 고려하신다면 몇 가지 아이디어를 제안합니다:
- 사용자가 전역적으로 또는 채팅별로 선호하는 스타일을 선택할 수 있는 사용자 설정을 고려해 보세요.
- ‘자동으로’ 어떤 형식을 사용할지 결정할 때 채팅 공간의 사용자 수, 메시지 빈도, 평균 답글 깊이를 고려해 보세요. 예를 들어, 체인 내 답글이 특정 숫자에 도달하거나 사용자가 "답글을 스레드로 변환"을 표시할 때까지 인라인을 사용하는 것입니다.
- "어제/지난주 무언가에 대한 새 답글 스레드를 만들고 있다"는 상황을 고려하고, 답글을 표시하는 것이(또는 Slack처럼 응답자가 답글을 인라인으로 게시하도록 허용하는 것이) 합리적인지 생각해 보세요.
현재 가지고 있는 것은 괜찮다고 생각하지만, 이 기능이 앞으로 나아가면서 이 두 가지 명확한 방법론 사이의 장벽을 흐리게 하는 것을 Discourse가 고려해 주기를 바랍니다.
7개의 좋아요
매우 잘 정리되고 건설적인 의견에 감사드립니다.
말씀해 주신 내용을 잘 들었습니다. 대부분의 지적 사항은 우리도 최소한 몇 번은 생각해 본 부분들이었습니다. 채팅 기능이 점점 더 성숙해지고 널리 활용되면서, 이 문제가 가까운 미래에(약간) 해결될 것이라고 확신합니다.
8개의 좋아요
특정 한도까지 모든 스레드의 인라인 발췌본을 표시하는 방식으로 이 문제를 깔끔하게 해결할 수 있다고 생각합니다. 댓글이 적다면 모두 읽을 수 있고, 많다면 일부만 인라인으로 표시됩니다. 이렇게 하면 대화가 어떤 내용인지 한눈에 빠르게 파악할 수 있으며(관심이 있다면 해당 서브스페이스로 진입하면 됩니다).
3개의 좋아요
이것은 내 생각에 포럼 주제에도 해당됩니다. 첫 번째 댓글/답글과 최신 댓글/답글의 스니펫을 모두 상단 목록 레벨에서 보고 싶습니다. 이렇게 하면 빠르게 훑어보기가 쉬워지거든요. 저는 비슷한 시스템을 구축하고 실험해 봤는데, 최신 몇 개의 답글이 계속 업데이트되는 것을 관찰하기만 하면 여러 스레드를 동시에 모니터링할 수 있었습니다. (참고: 이것은 아래로 병합된 별도의 게시물인 위 게시물에 대한 답글이었습니다)
어느 시점에 주제가와 스레드가 동일한 기반 시스템이 될 것이라고 가정합니다. 이는 주로 UX/표현상의 차이일 뿐이죠? 그렇지 않으면 동일한 기능과 기능을 둘 다 위해 중복해서 만들어야 할 것입니다.
1개의 좋아요
현재 토론에 스레드를 도입할 계획은 없습니다. 이는 채팅 전용 기능입니다.
다만, 스레드형 답변 도입에 대한 기존 토론이 많이 있습니다. 해당 토론 중 하나에서 대화를 이어나가시기를 원하시면요?
제가 말하고자 하는 것은, 스레드가 있는 채팅이 주제 기반 포럼과 크게 다르지 않다는 것입니다. 디스코스에 새로운 기능이 추가되면, 포스트 그리고 채팅 메시지에 모두 적용되기를 원하게 될 것이며, 만약 이 둘이 기술적으로 동일한 핵심 시스템 위에 구축되어 있다면 구현이 훨씬 쉬워질 것입니다.
1개의 좋아요
저 역시 수렴을 지지합니다. 전반적으로 장기적으로 가장 견고한 접근 방식이라고 생각하며, 기능 추상화가 동일한 부분을 인식하여 실제로 그렇게 만드는 것이 그 이유입니다. 예를 들어, 저는 한때 태그를 '메타 카테고리’의 한 형태로 고려하자고 제안한 적이 있습니다.
1개의 좋아요
게시글이 새 주제로 분리되었습니다: 채팅 메시지에 답글을 작성하여 스레드를 만들 수 없음
이 기능이 이미 충분히 안정화되었으므로, 이 공지사항 주제를 닫겠습니다. 
해당 기능에 대한 문제나 개선 사항이 있으시면, Support, Contribute > UX 또는 #contribute:feature에 새로운 주제를 생성해 주세요.
7개의 좋아요