할당된 메시지 및 주제 목록에서 결과를 필터링할 수 있으면 좋겠습니다. 예를 들어, 하나 이상의 태그로 필터링하는 것 같은 기능 말이죠. 예전에는 가능했던 것 같은데, 지금은 어떻게 해야 할지 막막합니다.
제 디스코르스에서 내 할당 목록이나 동료의 할당 목록을 볼 때, 
를 선택하면 “@tobiaseigen의 게시물 검색” 체크박스가 표시됩니다. "@tobiaseigen에게 할당된 항목 검색"이라고 표시되는 것이 훨씬 합리적일 것 같습니다.
고급 검색 화면에는 "할당된 항목"으로 필터링하는 UI가 없는데, 할당 플러그인을 사용하는 사이트에서는 이 기능이 매우 유용할 것 같습니다. 로드맵에 이 기능이 계획되어 있나요?
검색하다가 검색용 "마법 필터"를 위한 도움말 인터페이스를 만들자는 오래된 주제를 발견했습니다. 그 아이디어가 어떻게 되었는지 모르겠지만, 정말 좋은 아이디어라고 생각합니다! 아니면 최소한 어떤 필터링이 가능한지 전체 목록이 어딘가에 있다면 보고 싶습니다.
불행히도 여기서는 주제 목록의 사용자 정의 필터만 있고, 검색용 필터는 없습니다. 추가하는 건 어렵지 않을 텐데요. 좋은 기능 요청입니다.
이 부분을 생각해보면, 우리는 어떤 종류의 필터 문법을 원할까요?
아래와 같이 생각하고 있습니다.
status:assignedstatus:unassignedassigned:{{username}}@tobiaseigen @sam, 이 방식이 적절한가요?
나쁘지 않네요! 감사합니다.
고급 검색에 정말 멋진 개선이 될 것 같습니다! 우리는 현재 Discourse를 태스크 관리 및 헬프데스크 애플리케이션으로 사용하고 있으며, 이 필터를 구현하면 처리되지 않은 작업을 식별하는 능력이 확실히 향상될 것입니다. Discourse를 한 달 동안 사용하면서 이미 이 제품에 완전히 매료되었습니다! 정말 훌륭한 제품을 만들어 주셔서 감사합니다!
좋네요! 다음 링크들을 확인해 보셨나요?
그리고
사용 사례에 대한 피드백을 받을 수 있으면 좋겠습니다.
좋은 소식입니다! @Ahmed_Gagan 님이 이 작업을 진행 중이며, 곧 사용하실 수 있도록 준비될 예정입니다! 
@Ahmed_Gagan @david 두 분 모두 감사합니다! 이 개선 사항은 우리 팀과 고객에게 큰 도움이 될 것입니다. 좋은 일 계속 이어가세요.
Discourse for Teams에 대한 조언을 주신 @tobiaseigen님께 진심으로 감사드립니다. 또한, 정말 기쁜 소식입니다, @david님! 이제 훌륭한 업무를 관리하는 것이 훨씬 쉬워질 것입니다. 이 게시글을 통해 Discourse로 전환하게 만든 핵심 기능들이 무엇이었는지 말씀드리고 싶습니다.
저희는 콜롬비아 시장을 대상으로 비즈니스 관리 솔루션을 구축하는 데 전념하는 소프트웨어 개발자, 기능 분석가, 시스템 관리자로 구성된 팀입니다. 물론, 전 세계가 저희의 로드맵에 포함되어 있죠 ;). 저희는 고객사를 위한 맞춤형 소프트웨어를 구축하고 자체적인 독창적인 제품도 보유하고 있지만, 현재 저희의 주요 사업은 Odoo ERP 위에 서비스와 확장 기능을 제공하는 것입니다. Odoo에 포함된 모든 애플리케이션 중에서도 저희는 회계, 재고 관리, 인사 관리 분야에 특화되어 있습니다. 예상하셨을 것처럼, 저희는 스스로도 Odoo을 광범위하게 사용하고 있으며, 2015년 창립 이래로 그 프로젝트 관리 애플리케이션이 저희 팀의 가장 큰 동맹군이었습니다. 이 애플리케이션의 칸반 인터페이스(Trello 스타일) 덕분에 각 구현 프로젝트의 합의된 작업 워크플로를 관리할 수 있었습니다. 그러나 프로젝트 구현은 고객사와의 관계의 시작에 불과하며, 효율적인 관리와 대외 커뮤니케이션이 제공되지 않으면 유지보수 단계에서 상황이 복잡해질 수 있습니다. 하지만 Odoo에는 이메일을 통해 소프트웨어 사용자와 티켓 기반의 커뮤니케이션을 관리할 수 있는 헬프데스크 애플리케이션이 있으며, 물론 저희도 이를 지원 서비스 제공에 사용해 왔습니다. 기능적 질문에 대한 빠른 답변은 이 도구를 통해 쉽게 관리할 수 있었지만, 복잡한 버그 보고서가 접수되면 개발 과정을 돕기 위해 별도의 문서를 생성해야 했습니다. 이러한 경우, 저희는 벤더에 종속되지 않는 이슈 보고 형식을 확립하기 위해 Gitlab과 Github Issues를 사용했고, 심지어 Python으로 내부 개발한 도구로 파싱하는 커스텀 버전 관리된 RestructuredText 파일까지 사용했습니다. 결국, 수행해야 할 작업을 최소 3개의 서로 다른 곳에서, 서로 다른 인터페이스와 워크플로를 사용하여 찾아야 하는 상황에 처하게 되었습니다. 일상적인 활동을 수행하기 위한 대외 및 대내 커뮤니케이션 모두 위기에 처했고, 이는 저희가 "Odoo 중심주의"가 깨지더라도 대안적인 프로세스와 도구를 찾게 만들었습니다. Discourse는 수년 전부터 포럼 소프트웨어로 매우 유명했지만, 저희는 몇 가지 조사를 한 후 최근에야 그 활동 관리 기능에 대해 알게 되었습니다. 저희가 이를 시도하게 만든 것은 3가지 이유였습니다: 비동기 커뮤니케이션, 작업 정의의 균질화, 그리고 WIP(진행 중인 작업) 제어.
Discourse 게시글은 이메일과 비슷하지만 더 좋습니다. WhatsApp, Slack, Messenger, Mattermost, Odoo Chat 등 수많은 채팅 앱이 있는 세상에서, 우리는 항상 ‘경계’ 상태에 익숙해져 있습니다. 모든 것이 긴급해 보이기 때문에 짧고, 빠르고, 얕은 답변으로 즉각 응답하도록 압박받습니다. 생각할 시간도, 수정할 시간도 없습니다. 그저 쓰고 보내기만 하면 됩니다. 예를 들어 이 게시글을 작성하는 데는 예상보다 훨씬 더 많은 시간이 걸렸지만, 저는 더 시급한 다른 업무들을 마친 후에 작성하고 있기 때문에 가장 진심 어린 세심한 피드백을 제공하도록 집중할 수 있었습니다(Discourse와 같은 훌륭한 도구라면 제가 할 수 있는 최소한의 일입니다). 게시글을 작성하는 것은 이메일을 보내는 것과 같지만, 읽는 것은 전혀 다른 이야기입니다. 훨씬 더 나은 이야기입니다. 게시글은 팀의 모든 멤버(또는 권한이 있는 사람들) 사이에 중앙 집중식으로 공유됩니다. 내용이나 위치(예: 주제와 카테고리)로 검색할 수 있으며, 원래 대화에 참여하지 않은 외부 사용자나 직원도 접근할 수 있어 결정이 어떻게 내려졌는지와 그 맥락에 대한 역사적 기록을 보관하는 데 매우 유용합니다. 참고: python.org가 메일링 리스트나 기타 Python 기반 솔루션 대신 커뮤니티 관리 애플리케이션으로 Discourse를 채택한 방식을 보면, 여기 있는 것이 적합성, 성능, 접근성 측면에서 정말로 탁월하다는 것을 알 수 있습니다.
이것이 저희가 Discourse로 전환하는 주된 이유입니다. 앞서 언급한 배경을 통해 매우 다채롭고 복잡한 업무 환경을 상상하셨을 것입니다. 사실 저는 약간 과장한 면이 있습니다. 저희는 창립 초기부터 활동을 관리하기 위한 문서화된 프로세스와 디지털 도구를 효과적으로 갖추고 있었기 때문입니다. 하지만 시간이 지나면서 겪게 된 문제는 회사 내에 작업의 단일 표현을 갖지 못했다는 것입니다. 네, 컨설팅 활동에는 작업이 있었고, 지원에는 티켓이 있었습니다. 개발은 일반 텍스트로 문서화된 요구 사항이나 잘 알려진 Git 관련 이슈를 통해 진행되었습니다. 이는 부족함의 문제가 아니라, 오히려 과잉의 문제였습니다. 정보원이 너무 많았고, 심지어 공통 애플리케이션(예: Odoo) 안에서도 여러 형식의 정보가 존재했습니다(예: 작업, 티켓, 이슈). 물론 aforementioned 도구 중 하나를 유일한 진실의 원천으로 선택할 수도 있었지만, 그중 어느 것도 우리에게 하나의 결정적 요소를 제공하지 않았습니다: 통합된 외부 피드백. Discourse를 사용한 지 불과 한 달 만에 마침내 저희 제품의 사용자들과 연결되고 있다는 느낌을 받고 있습니다. 그들과 우리 사이의 구분이 없습니다. 왜냐하면 우리는 모두 동일한 인터페이스를 사용하기 때문입니다. 그러나 우리는 어떻게 작업을 관리하는지에 대한 통제를 포기할 필요는 없습니다. 일부 영역과 기능은 제한할 수 있기 때문입니다. 하지만 가장 좋은 점은 Discourse의 **주제(Topics)**를 통해, 블로그 댓글이나 헬프데스크 티켓과 유사한 이러한 산출물들이 고객의 필요를 이해하는 데 사용되던 것들이, 이제 저희가 비공개 내부 사용 카테고리에서 수행할 계획된 작업, 처리할 이슈, 또는 실행할 운영 활동을 표현하는 데 사용될 수 있다는 것입니다. 저희에게 주제(Topic)는 여러 동의어를 가지며, 모두 맥락에 따라 유효합니다: 이슈, 작업, 티켓, 활동, 체크리스트 등, 뭐라고 불러도 됩니다. 개방적이고 접근하기 쉬우며 중앙 집중식으로 관리되는 균질한 형태의 작업. 저는 Discourse for Teams가 Discourse 포럼과 다른 별개의 제품으로, 즉 Discourse(포럼)와 Discourse for Teams가 두 개의 다른 인스턴스로 배포되도록 의도되고 있다는 것을 읽었습니다. 이 설계는 조직의 외부와 내부 당사자 간의 현재 제공되는 통합을 필연적으로 분절시킬 것이므로, 신중하게 고려해 보시기를 권합니다.
마지막으로, Discourse 사용으로 경험한 최고의 놀라움 중 하나는 마침내 조직 내 진행 중인 작업(WIP)에 대한 제어를 확립할 수 있게 되었다는 것입니다. 수행할 작업이 모두 동일한 "형태"를 가지고 있기 때문에, 조직이 어떤 시점에든 가져야 할 작업의 양을 제한하는 정책을 정의하기가 쉽습니다. Assign 플러그인을 통해 작업에는 고유한 책임자가 지정되며, 필요한 경우 도움을 요청할 수 있습니다(이는 ‘@’ 한 번이면 됩니다). 그리고 통합된 인터페이스(경로: '/g/staff/assigned/everyone’에서 찾을 수 있음)를 사용하여 시스템 전체의 진행 중인 활동(즉, WIP)의 양을 제어할 수 있습니다. 예를 들어, 현재 저희는 1인당 WIP를 5개의 작업/주제/이슈로 설정하고 반복하고 있습니다. 저희는 14명이므로, 팀으로서의 최대 용량은 70이어야 합니다. 이는 저희에게 매우 중요합니다. 왜냐하면 그것은 인생에서 가장 어려운 과업 중 하나인 '추정’에 안정성을 제공하는 데 도움이 되기 때문입니다. 리틀의 법칙(Little’s Law, Little's law - Wikipedia)에 따르면, 대기열 내 요소의 장기 평균 수는 그 평균 도착률(또는 처리량)에 각 요소가 시스템에 머무는 평균 대기 시간을 곱한 것과 같습니다. 따라서 70개 요소로 제한된 WIP에서, 주당 140개의 티켓을 수신하면 평균적으로 0.5주에 완료될 것이며, 주당 210개를 수신한다면 평균 0.33주에 완료되어야 합니다. 물론 이는 시스템이 안정된 상태에 있고 백로그가 무한정 증가하지 않는다고 가정하며, WIP의 적절한 보정은 반복적인 방식으로 수행되어야 합니다. 여전히(그리고 항상) 이메일 메시지 관리나 CRM 파이프라인 관리처럼 Discourse에서 표현할 수 없는 소량의 작업 유형이 있지만, 수행할 작업의 대부분이 이제 Discourse 주제라는 단일 형태를 가지므로, WIP 제한과 같은 칸반 및 Agile 관행을 구현하는 것이 훨씬 쉬워질 것입니다. 따라서 Discourse for Teams가 Discourse 포럼의 별개 인스턴스로 의도된다면, 두 시스템 모두에서 WIP에 대한 중앙 집중적이고 복합적인 뷰를 유지하는 연방(federated) 방식이 없다면 아쉽다고 조언하고 싶습니다.
이 게시글이 Discourse를 커뮤니케이션 및 커뮤니티 구축 플랫폼으로서 개선하는 데 도움이 되기를 바랍니다. 다시 한번 감사드리며, 모두에게 최고의 행운을 빕니다!
