채팅에서 시작된 대화가 주제(Topic)로 이어질 가치가 있을 때, 현재 이를 수행하는 가장 좋은 방법은 무엇인가요?
사람들이 그것이 적절한 시점이라고 느낄 때 그 전환을 더 자연스럽게 할 수 있도록 무엇을 할 수 있을까요?
@Don은 경우에 따라 메시지를 게시물로 변환하는 옵션이 더 나을지 궁금해했으며, 저는 오늘 채팅 기록을 사용하여 “주제 내에서 인용” 기능을 활용하고 새로운 게시물을 작성하여 이어지는 논의를 시작하는(지금 제가 여기서 시도하고 있는 것처럼) 방법에 대한 몇 가지 아이디어를 공유했습니다.
안녕하세요, 스태프를 위한 (채팅 메시지를 일반 게시글로 이동하거나 변환하는) 기능을 다시 도입할 계획이 있나요? 우리는 지원용(빠른 Q&A) 채널을 운영해 왔는데, 회원들이 해결책으로 표시하는 기능이 매우 그리워하고 있습니다. 채팅 내에 매우 의미 있는 대화들이 많아서 이를 일반 주제로 옮겨 더 의미 있는 대화로 만들고 더 많은 주목을 받고 싶습니다. 하지만 인용이 이 목적에 가장 좋은 옵션은 아닌 것 같습니다. 이 부분에 대한 답변을 놓쳤다면 죄송합니다. 감사합니다
mcwumbly
@Don 짧은 답변은 '아니요'입니다. 하지만 우리가 계획 중인 다른 몇 가지 사항이 여기서 도움이 될 수도 있을까요? 확실하진 않습니다. 현재 관찰하고 있는 행동의 종류와 왜 '주제로의 인용'이 적절하지 않게 느껴지는지 더 잘 이해하려면 이 내용을 더 자세히 풀어서 설명해야 할 것 같습니다.
dodesz
안녕하세요 Dave, 답변 감사합니다. 인용이 이 목적에 충분하지 않다고 느껴지는 이유: 원래 작성자가 유지되지 않기 때문입니다. 즉, 누군가를 인용하면 게시글이 원래 작성자의 것이 아니라 제 것이 됩니다. 누군가가 답장하거나, 좋아요를 누르거나, 기타 행동을 하면 알림이 원래 작성자가 아니라 저에게 옵니다. 또 다른 문제는 여러(많은) 채팅 메시지를 인용하면 매우 긴 첫 번째 게시물(OP, 게시물의 본문)이 생성된다는 점입니다. 특정 인용 메시지에 답장하려면 사용자는 해당 메시지를 다시 인용해야 합니다. 그렇지 않으면 누가谁的 메시지에 답장하는지 알 수 없습니다. 인용은 새로운 주제를 만들고 채팅 메시지의 일부를 참조할 때 유용합니다. 하지만 단순히 대화를 일반 주제로 이동하거나 변환하려는 목적에는 이러한 점들로 인해 가장 좋은 옵션이 아닌 것 같습니다. 하지만 아마도 다르게 생각해 봐야 할 수도 있고, 우회 방법(workaround)이 있을 수도 있으며, 아니면 채팅과 일반 주제/게시글을 분리해서 처리해야 할 수도 있습니다.
mcwumbly
아마도 다르게 생각해 봐야 할 수도 있고, 우회 방법(workaround)이 있을 수도
제가 추천하는 우회 방법은 채팅 기록을 주제 자체보다는 새로운 주제에 대한 "맥락(context)"으로 생각하도록 하는 것입니다. 주제를 생성한 사람은 자신의 언어로 내용을 요약할 수 있고(해야 합니다). 이는 모더레이터인 당신일 수도 있고, 채팅 논의를 시작한 사용자일 수도 있습니다(당신의 작은 격려가 있을 경우).
저는 이 논의를 통해 제가 말하는 바를 시연할 기회를 가질 것입니다.
인용 기능을 개선하여 주제 내에서 채팅 기록의 일부를 인용할 때 원래 작성자에게 귀속되도록 할 수 있을 것입니다(인용된 게시글에 대해 우리가 하는 방식처럼).
감사합니다, 데이브! 이제 이해가 되는 것 같습니다… 이건 마치 연결된 토픽으로 답글 기능과 비슷한 것 같아요. 인용문을 개선하는 것만으로도 제 사용 사례는 충분히 해결될 수 있다고 생각합니다. 인용문을 더 개선하거나 동적으로 만드는 방법에 대해 몇 가지 아이디어가 있습니다.
채팅 인용문과 원래 채팅 메시지를 서로 동기화하여 (답글, 공유, 빠른 인용, 그리고 아마도 반응 등) 일부 작업 버튼을 포함할 수 있고, 사용자는 인용된 채팅 메시지와 더 쉽게 상호작용할 수 있습니다…
이를 동기화 가능하게 만드는 난이도를 정확히 알 수는 없지만, 아마도 가장 쉬운 수준은 아닐 것입니다. 하지만 이 경우 동기화는 반응 기능에만 사용되므로 생략해도 될 것 같습니다. 따라서 채팅 인용문에는 공유 및 답글 버튼만 포함됩니다. 공유는 원래 채팅 메시지의 링크를 복사하고, 답글은 인용된 채팅 메시지를 자동으로 인용하거나 연결하여 작성기를 여는 방식입니다. 그냥 아이디어일 뿐입니다…
채팅에서 메시지를 이동시켜 새로운 주제를 만드는 것이 가능한지 궁금합니다. 새로운 주제의 첫 번째 메시지에 모든 메시지를 긴 인용문으로 넣는 방식은 제외하고요.
사용자들이 채팅방에서 정말 훌륭한 토론을 시작하는 경우가 종종 있습니다. 이런 토론은 포럼의 주제로 전환되면 아주 효과적일 것 같습니다. 문제는 채팅방에서는 이런 토론이 하루 이틀 만에 사라지고 검색 엔진에 인덱싱되지 않는다는 점입니다. 훌륭한 토론을 새로운 주제로 승격시킬 수 있는 기능이 정말 필요한 것 같습니다.
채팅 메시지를 댓글로 사용하는 새 주제를 만드는 것만을 말하는 것이 아닙니다. 이상적으로는 채팅 메시지를 채팅방에서 제거하고 모든 것을 주제로 이동하는 것입니다. 인용(quoting)의 문제는 사용자가 아무 일도 없었던 것처럼 채팅에서 토론을 계속할 수 있다는 점입니다.
지금으로서는 토론이 식을 때까지 기다린 후 인용을 사용하여 주제를 아카이빙하는 것이 최선의 방법인 것 같습니다.
다른 커뮤니티 매니저분들은 어떤지 모르겠지만, 저는 채팅이 자연스럽게 좋은 주제들을 만들어내는 데 매우 유용하다고 생각합니다. 특히 주제 생성을 좋아하지는 않지만 채팅과 댓글을 좋아하는 사용자 기반을 보유하고 있다면 더욱 그렇습니다.
채팅과 포럼이 원활하게 통합되는 것은 꿈만 같은 일일 것입니다. 예전에는 채팅 목적으로 매우 긴 주제들을 사용했지만, 안타깝게도 Discord 같은 서비스와 비교하면 충분하지 않았습니다. 어쨌든 Discourse가 엔진에 채팅 기능을 통합하고 있는 것을 보니 기쁘고, 언젠가 채팅과 포럼이 완벽하게 결합된 하이브리드 형태로 발전하길 기대하고 있습니다.
선택한 메시지를 토픽으로 이동합니다. 그런 다음 채널에서 해당 메시지를 삭제합니다(이 부분은 꽤 귀찮은데, 우습고 엉성한 트릭 없이 일괄 삭제가 불가능하기 때문입니다). 그리고 마지막 단계로, 채널에서 내가 무엇을 했는지 설명하고 해당 토픽으로의 링크를 제공하면서, 그곳에서 대화를 계속해 달라고 겸손하게 요청합니다.
저는 어제 Discourse 채팅을 활성화했기 때문에 현재 제한 사항에 대해 충분히 파악하지 못했습니다. 지금은 채팅 메시지와 게시글, 채팅 채널과 주제 사이에 명확한 구분이 있는 것을 확인했습니다. 지금 새 대화를 만들려면 채팅 채널로 만들지, 아니면 주제로 만들지 선택해야 합니다. 이 선택을 나중에 변경하거나 되돌릴 수 없습니다.
채팅과 포럼의 통합이 원활하다고 하려면, 주제를 만든 후에 채팅방으로 전환할지 아니면 주제로 남길지 나중에 결정할 수 있어야 한다고 생각합니다. 주제를 채팅 채널로, 채팅 채널을 주제로 변환할 수 있는 기능이 필요합니다.
오해하지 마세요. 완전히 별도의 채팅 플랫폼을 사용하거나, 심지어 로그인 게이트웨이 없이 사용하는 것보다는 Discourse 채팅이 여전히 낫습니다.
Daniel이 어떻게 보는지는 모르겠지만, 채널 링크를 걸고 인용을 보여주는 방식은 인용 시점에 채팅에 대한 일종의 광고 역할을 합니다. 시간이 좀 지나면, 예를 들어 한 달이나 일 년 뒤에는 더 이상 중요하지 않지만, 읽는 것을 약간 어렵게 만듭니다.
이것을 너무 심각하게 받아들이지 마시기 바랍니다. 저는 작은 테스트를 하나 해보았습니다. 제 활성 멤버들이 어떻게 행동하고 반응하는지를 꽤 잘 알고 있으므로, 이 점에 대해 신뢰를 두었습니다(음… '신뢰’라고 표현하기엔 영어 실력이 부족하고, 제가 쓰고 싶은 단어를 찾지 못하겠습니다. 긍정적인 직감 같은 거죠).
채팅에서 토픽으로 일반적인 복사(시작 글이나 댓글, 무엇이든)를 하면 그 논의는 끝납니다. 하지만 시간을 들여 그 인용들을 개별 댓글로 나누고 소유권을 올바른 사람들에게 변경하면, 그 논의는 계속됩니다.
따라서 사용자가 일반적인 토픽 대신 긴 인용을 볼 때, 어떤 식의 심리적 장벽과… 개인적인 감촉/느낌이 부족하다는 것이 있어야 합니다.
이를 어떻게 해결할 수 있을까요? 저는 모르겠습니다. 저는 필요한 수작업 토픽 편집보다 제 여가 시간을 더 소중히 여기며 그리고 CDCK에게는, 그리고 확실히 저에게는도 그런 자동화를 만드는 것이 너무 비쌉니다. 결국 그것은 일종의 또 다른 특수 사례(edge case)이기 때문입니다.