정말 감사합니다!
어젯밤에 스택 전체에서 테스트가 통과하는 상태로 첫 번째 AC 두 개를 구현했습니다(다만 아직 라이브 환경에서는 테스트하지 않았습니다). 단, 전사(transcript) 플로우에는 아직 적용하지 않았습니다. Topic에 커스텀 필드를 사용하고 thread 규칙을 적용하는 방식으로 구현했습니다. 따라서 적어도 초안 PR에서 코드를 보여줄 수 있을 정도로 좋은 진전을 이루고 있습니다.
또한, 사용되지 않는 pstore_get을 slack 프로바이더에서 제거하는 별도의 커밋도 작성해 두었습니다. pstore의 유일한 사용처가 이것이라면, 해당 정리 커밋에서 app/initializers/discourse_chat.rb의 모든 pstore_*도 함께 제거해 드릴까요?
저도 정확히 그 부분에서 시작했고, 그렇게 했다면 훨씬 쉬웠을 것입니다!
하지만 제 사용 사례(그리고 다른 회사에서도 비슷한 이야기를 들었으니 우리만의 문제는 아닙니다)를 고려할 때, 스레드 사용 여부에 대한 선호도가 채널마다 다릅니다. 스레드를 사용하도록 설계된 채널(대부분의 사람들이 일부 주제에만 관심을 두기 때문)과 스레드를 극도로 꺼리는 채널(스레드가 중요한 정보를 묻어버리기 때문)이 있습니다.
이 선호도를 이끄는 본질적으로 무관한 두 가지 측면을 확인했습니다:
- 소속: 수십 년간 IRC를 능숙하게 사용해 온 멤버들이 대부분인 채널은 단일 채널 내 뒤섞인 대화 스레드를 정신적으로 구분하는 데 익숙하며, 중요한 내용을 보기 위해 스레드를 클릭하는 것을 원하지 않습니다. 반면, 이메일 환경에서 생활해 온 멤버들이 대부분인 채널은 대화가 스레드 형태로 구성되고, 관심 있는 대화를 클릭해서 보는 것을 기대합니다.
- 목적: 공지사항 성격의 비즈니스 목적을 가진 채널은 공격적으로 스레드를 사용하는 경향이 있지만, 연구나 협업 목적의 채널은 의도적으로 스레드를 사용하지 않는 경우가 많습니다. 이는 스레드가 정보를 숨기며, 이를 알아채고 클릭하지 않는 한 접근할 수 없기 때문입니다.
규칙 옵션에 대해 공통 구문을 원하신다면, Rule을 :tags와 마찬가지로 배열인 :options 값을 가질 수 있도록 일반적으로 확장하는 것이 좋다고 생각합니다. 커맨드라인 셸의 방식을 차용하는 것도 합리적일 수 있습니다. 예를 들어 /discourse [watch|follow|mute] -something -here를 입력하면 :options가 ['something', 'here']로 설정되는 방식입니다. 여기서 앞선 -는 옵션을 도입하는 용도로 예약됩니다. 그러면 /discourse watch my-category-slug #tagged-foo -threaded와 같이 사용할 수 있습니다. 제가 이미 한 일보다 이 방식이 얼마나 더 많은 작업을 필요로 하는지 확신은 없습니다. 이 문제에 대해 강한 의견이 있으신가요? 양쪽 모두 논리가 성립합니다: Rule에 값을 하나 더 추가하면 채팅 프로바이더를 작성하는 것이 더 복잡해지고, 필터 값을 하나 더 추가하면 슬랙 전용 기능(예: 전사 게시)이 하나 더 생겨 슬랙 외 사용자에게 인터페이스가 더 복잡해집니다. 물론 제가 놓치고 있는 부분이 있을 수 있습니다. 예를 들어, 카테고리 슬러그가 -로 시작할 수 있다면 갑자기 모호해지거나, 셸은 --를 "이 이후의 모든 것은 인수가 아님"으로 사용하지만, 우리는 --를 "이 이후의 모든 것은 옵션"으로 반전할 수도 있습니다. 이 부분을 조사해 보기를 원하신다면, 규칙 옵션을 지정하는 데 적절하다고 생각하시는 구문에 대해 방향을 잡아 주십시오. 하지만 단순히 thread를 추가하는 것이 제게는 더 단순해 보이므로, 일반적인 “옵션” 기능을 추가하라는 구체적인 지시가 없다면 그 방향으로 변경을 보류하겠습니다.
[편집: 필터를 옵션으로 변경하는 것은 UI를 확실히 복잡하게 만들 것입니다. UI는 일반적인 옵션에 대한 일반적인 지원을 위해 확장되어야 하므로, 이는 좋은 선택으로 보이지 않습니다. 따라서 이제 UI를 살펴본 결과, 필터를 유지하는 편이 더 깔끔하다고 생각합니다.]
게시물 전사 플로우에 대해, HTML 주석 아이디어에 감사합니다. 제 사용 사례에서는 이로 인해 불이익이 되지 않을 것입니다. 솔직히 말해, 적어도 초기에는 제가 주요 사용자가 될 것으로 예상합니다. 아주 간단하고 좋은 해킹(hack)입니다.
이 PR에 포함시키지는 않겠지만, 게시 중인 메시지의 채널에서 결과적으로 생성되는 디스코urs 포스트가 만들어질 범주로 매핑하는 기능이 있으면 좋겠다는 별도의 아이디어가 있습니다. 이를 위해, 전사(envelope)나 사이드카(sidecar)를 도입하는 것이 가장 좋다고 생각합니다. 그러면 그 envelope이나 sidecar에 카테고리 ID와 슬랙 ID를 모두 포함할 수 있습니다. 저는 여전히 Ruby on Rails 학습의 "고급 구글링 단계"에 있으므로, 이는 저에게 상당한 학습량이 될 것입니다. 
