진행 중인 실험에 대해 여러분께 말씀드리고자 합니다. 저보다 커뮤니티에 대한 기억력이 좋은 분들이 계실 테니, 제발 알려주세요!
최근 Support 카테고리에서의 경험을 고려할 때, 마지막 답변 후 30일이 지나면 주제가 자동으로 닫히도록 설정하는 것이 적절하다고 생각하여 그렇게 설정했습니다. 그 시점까지 주제가 해결되었거나, 질문한 사람이 다른 곳으로 이동해 있을 가능성이 높습니다. 비슷한 질문을 가진 다른 사람들은 자신의 상황에 맞는 새로운 주제를 시작할 수 있습니다.
지난 몇 달간 저는 사이드바에서 이 필터를 사용하여 해결되지 않은 오래된 Support 주제를 분류해 왔습니다. 질문을 매우 세심하고 친절하게 답변해 주는 멤버들 덕분에 많은 경우 주제가 비교적 빠르게 해결됩니다. 때로는 질문자의 문제가 해결되었는지 확인하고, 도움이 될 수 있는 추가 질문(재현 단계는 무엇인가요? 공식 설치 지침을 사용하셨나요? 안전 모드에서 작동하나요? 등)을 하기 위해 일주일에서 두주일 정도 지난 후에 주제를 살피는 것이 필요합니다. 이렇게 할 때 저는 보통 마지막 답변 후 30일이 지나면 자동으로 닫히도록 주제 타이머를 설정합니다. 30일 이내에 해당 사람이나 커뮤니티의 다른 멤버가 응답하지 않으면 주제가 자동으로 닫히는 것이 전혀 문제없다고 생각합니다.
#support에 게시된 주제들이 어떻게 검색되는지 생각해 보셨나요? 해당 카테고리가 기본 선택되어 있고, 이후 커뮤니티 구성원들에 의해 다른 카테고리로 이동하기 때문이죠. 저는 주제를 이동할 수는 있지만, 타이머를 제거할 수는 없습니다. 그래서 제가 주제를 이동한 후에는 다른 누군가가 타이머를 제거해야 합니다.
-- [params]
-- date :start_date
-- date :end_date
SELECT
pr.user_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id,
COUNT(*) AS change_count
FROM post_revisions pr
WHERE pr.modifications LIKE '%category_id:%'
AND pr.modifications ~ 'category_id:\s*-\s*[0-9]+\s*-\s*[0-9]+'
AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
GROUP BY pr.user_id, old_category_id, new_category_id
ORDER BY pr.user_id, change_count DESC
이 플러그인은 시작 카테고리 선택기를 제공하며, 해당 카테고리에서 날짜별로 이동된 개별 주제를 나열합니다:
-- TOPICS MOVED LIST
-- [params]
-- date :start_date
-- date :end_date
-- category_id :cat_id
SELECT
pr.user_id, pr.post_id, pr.updated_at,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id
FROM post_revisions pr
WHERE (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int = :cat_id::int
AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
ORDER BY pr.updated_at DESC
저는 당신보다 “커뮤니티 기억력이 더 좋은” 사람은 아니지만, 참고로 당신의 접근 방식은 합리적으로 들립니다. 미해결된 주제를 검토해 주는 사람이 있다는 점이 기쁩니다 — 그리고 제 이해가 맞다면, 답변이 전혀 없는 주제는 알림(bump)이 없으면 자동으로 닫히지 않는 것 같네요 (저도 그런 주제가 몇 개 남아 있습니다…)
모든 주제를 닫는 것의 이점이 무엇인가요? OP와 동일한 문제를 겪고 있는 사람들이 이미 존재하는 주제에 답글을 달 때, 해당 주제가 오래되었다고 해서 왜 문제가 되나요?
Discourse는 오프톱یک 답글을 몇 번의 클릭만으로 새 주제로 분리할 수 있을 정도로 손쉽게 만들어 주며, AI Helper 덕분에 제목, 카테고리, 태그를 선택할 때 분석 마비(analysis paralysis)에 시달릴 필요도 없습니다. 제 생각에는 모든 지원 주제를 엄격하게 닫는 규칙은 구식이며, 구식 포럼 소프트웨어에서는 필요했을지 모르지만 지금은 그렇지 않다고 봅니다.
멋지네요! 여기까지 답변해 주셔서 감사합니다. 이 주제를 시작해서 사람들이 이에 대해 어떻게 느끼는지 알아볼 수 있어서 기쁩니다.
제가 틀렸을 수도 있지만, 최근 몇 달간의 제 경험에 비추어 볼 때 Support 카테고리는 현재 우리가 가진 다른 카테고리들과는 다르다고 느낍니다. 사람들은 문제를 바로 해결하러 옵니다. 그리고 거의 항상 그 문제는 해당 사용자의 고유한 상황에 매우 구체적입니다. 주제가 합리적인 시간 안에 해결되지 않으면, 그들은 흥미를 잃고 다른 곳으로 떠나거나, 인내심을 잃고 다른 주제에서 다시 질문합니다. 그 사이 지원 카테고리는 답변되지 않은 질문들로 가득 차게 됩니다. 이후에 온 다른 사용자들은 자신만의 약간 다른 질문을 하기 위해 그들을 다시 올립니다. 하지만 이런 질문들은 새 주제에서 하는 것이 훨씬 나을 것입니다.
이는 #support에서 다른 카테고리들과는 다릅니다. 다른 카테고리에서는 열린 주제(Open-ended topics)를 허용하고 장려합니다. 사람들이 #support에 다른 카테고리에 속하는 주제를 게시할 때, 예를 들어 실제로 Contribute > Feature 요청인 경우, 우리는 그들을 이동시킬 수 있습니다. 또는 플러그인 생성에 대한 도움이 필요한 경우, #dev로 이동시킵니다.
그러므로 어떤 방식으로든, 답변되지 않거나 논의가 흐지부지되는 Support 주제는 최종적으로 해결될 수 있도록 후속 조치가 필요합니다. 일주일 또는 두 주 후에 답변을 추가하고, 마지막 응답 후 30일 후에 닫도록 설정하는 것이 이것이 일어나도록 보장하는 합리적인 방법이라고 생각합니다.
여기서 제가 듣고 있는 것은, 우리가 주제를 자주 이동시키기 때문에(그것은 타이머를 제거해야 함을 의미합니다), 모든 Support 주제를 30일 후에 자동으로 닫는 것이 결국 올바른 접근 방식이 아닐 수 있다는 것입니다. 하지만 여전히 모든 Support 주제를 최종적으로 닫는 것을 목표로 해야 한다고 생각합니다.
그래서 지금은 자동 설정을 꺼두되, 제가 적절하다고 생각하는 경우에만 타이머를 추가할 것입니다. 만약 제가 타이머를 설정한 주제에서 타이머를 설정하지 말았어야 한다고 생각하신다면, 그 이유와 함께 알려주세요.
감사합니다! 해결했어요. 날짜나 월이 아니라 시간 단위로 지정되어 있어서 계산기를 꺼내야 했어요. 720시간이네요!
수정: 아, 그리고 직원 작업 로그를 확인할 수 있다는 걸 방금 기억났어요. 자동 닫기 타이머를 추가할 때 720을 제거한 기록이 남아 있긴 해요. 하지만 변경 사항을 저장할 때 UI에서 경고가 나오지 않은 건 좀 이상하네요. 이 문제를 Contribute > UX 토픽에서 지적했습니다.
Support 토픽의 경우, 거의 모든 상황에서 몇 주 안에 닫는 것이 목표라고 여전히 생각합니다. 도움을 요청하는 모든 사람이 적시에 답변을 받고 있는지 확실히 할 수 있는 유일한 방법이기 때문입니다. 그렇지 않으면 사람들은 신뢰를 잃기 시작하고, 다른 곳에서 답변을 구하게 될 것입니다.
토픽을 열어둘 이유가 있는 경우, 일반적으로 다른 카테고리로 이동시키기에도 적합하다는 점을 알아차렸습니다.
하지만 마지막 답변 후 30일이 지나면 Support 토픽을 자동으로 닫는 아이디어는 우리에게 적합하지 않다는 데 동의합니다. 실제로 문제가 해결되었는지 확인하고, 답변이 없거나 절반만 답변된 질문으로 카테고리가 가득 차는 상황을 피해야 하기 때문입니다.
