오늘날 우리 커뮤니티에서 가장 관리가 되지 않는 부분은 바로 이슈를 다루는 방식입니다. 맥락을 설명하자면, 우리는 자사가 개발한 제품을 사용하는 사용자들로 구성된 제품 주도형(product-led) 커뮤니티를 운영하고 있습니다. 여기서 '이슈’란 물론 버그, 기능 요청, 또는 일반적인 문제들을 의미하며, 실제로 GitHub 이슈와 유사합니다. 이슈는 다음과 같은 다양한 채널을 통해 접수됩니다:
- 우리(제 팀)가 소유한 코드/도구에 대한 GitHub 이슈
- 우리의 오픈소스 마켓플레이스에 대한 GitHub 이슈 (50개 이상으로 꾸준히 증가 중인 저장소/토픽)
- 우리 제품에 대한 일반적인 이슈/피드백/버그
- 커뮤니티 자체의 내부 이슈 (커뮤니티 기능 요청 등)
- 다른 사업 부서가 우리 팀에 제출하는 내부 이슈 (현재는 Slack으로 보내고 있음)
- 문서 관련 이슈
아래는 이 문제를 관리하기 위한 제 현재 정리되지 않은 생각들 중 일부입니다. 하지만 그 사이 다른 커뮤니티에서는 어떻게 하고 있는지 궁금해서 질문해 봅니다. 여러분은 어떻게 하시나요?
- 이 방정식의 일부는 일반적인 조직화 측면에서 카테고리와 태그 간의 영원한 고민입니다.
- 사용자는 가능한 태그의 수에 압도당하거나, 어떤 태그를 검색해야 할지 본능적으로 알지 못하며, 대부분의 경우 태그를 입력하는 시도조차 하지 않습니다. (n개의 태그를 요구하는 것은 일반적으로 최소한의 노력만 들여 태그를 입력하도록 강요합니다.)
- 1~2개 이상의 카테고리를 사용하는 경우, 포괄적인 제출 양식이 이 제출 과정을 완화하는 데 도움이 될 수 있습니다.
- Discourse가 추가할 수 있는 강력한 기능은 실험적 양식 템플릿의 필수 드롭다운 필드에 태그를 연결하는 것입니다. 예를 들어, 드롭다운 질문이 "어떤 브라우저를 사용하시나요?"라면, 답변 Chrome, Arc 등과 연관된 Discourse 태그가 생성됩니다.
- 이 솔루션에 대해 제가 가장 큰 문제로 꼽는 것은 '관리자 뷰’입니다. 티켓 플러그인(스크린샷이 깨져 있어 기억을 되살리지 못하지만)이 이 용도에 좋은 사례가 될 수 있다고 생각합니다.
- 이 맥락에서 주제에 대한 많은 메타데이터를 기반으로 조치를 취해야 합니다. 제출 날짜, 현재 상태, 연관된 태그, 담당자, 종료 기능 등.
