진행 중인 실험에 대해 여러분께 말씀드리고자 합니다. 저보다 커뮤니티에 대한 기억력이 좋은 분들이 계실 테니, 제발 알려주세요!
최근 Support 카테고리에서의 경험을 고려할 때, 마지막 답변 후 30일이 지나면 주제가 자동으로 닫히도록 설정하는 것이 적절하다고 생각하여 그렇게 설정했습니다. 그 시점까지 주제가 해결되었거나, 질문한 사람이 다른 곳으로 이동해 있을 가능성이 높습니다. 비슷한 질문을 가진 다른 사람들은 자신의 상황에 맞는 새로운 주제를 시작할 수 있습니다.
지난 몇 달간 저는 사이드바에서 이 필터를 사용하여 해결되지 않은 오래된 Support 주제를 분류해 왔습니다. 질문을 매우 세심하고 친절하게 답변해 주는 멤버들 덕분에 많은 경우 주제가 비교적 빠르게 해결됩니다. 때로는 질문자의 문제가 해결되었는지 확인하고, 도움이 될 수 있는 추가 질문(재현 단계는 무엇인가요? 공식 설치 지침을 사용하셨나요? 안전 모드에서 작동하나요? 등)을 하기 위해 일주일에서 두주일 정도 지난 후에 주제를 살피는 것이 필요합니다. 이렇게 할 때 저는 보통 마지막 답변 후 30일이 지나면 자동으로 닫히도록 주제 타이머를 설정합니다. 30일 이내에 해당 사람이나 커뮤니티의 다른 멤버가 응답하지 않으면 주제가 자동으로 닫히는 것이 전혀 문제없다고 생각합니다.
Have you thought about how you find the topics that were posted in Support, because that’s preselected and then moved to another category by community members? I can move topics, but I can’t remove the timer. So someone else needs to remove the timer after I’ve moved a topic.
Thanks for raising that point. It might be sufficient for you to flag it for moderators to make the change, unless you think you’re going to be doing this all the time. How often do you move topics between categories now?
Or you can ask data explorer to find out how many topics were moved
example query
-- [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
This mod provides a starting category picker, and lists individual topics moved out of that category by date:
-- 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
I’m not someone who’d “have better community memory” than you, but FWIW your approach sounds reasonable. I’m glad someone is reviewing unsolved topics – and if I’m reading you right, topics without any answering post will not be auto-closed without a bump (I have a couple of those hanging out there myself…)
@tobiaseigen I feel that topics are typically (and most commonly) moved in the 1-3 days since the topics are created. Perhaps the topic timer should be added from the 3rd day onwards to facilitate a but of buffer time while topics are moved? Though I doubt if that’s possible without a plugin.
What benefit is there for closing all topics? Why is there a problem to people, when facing the same issues as the OP, to add a reply to an already existing topic, even if said topic is old?
Discourse makes is so seamless to break off-topic replies into a new topic with so few clicks, and thanks to AI Helper you don’t even have analysis paralysis deciding title, category and tags, that in my opinion a strict rule on closing all support topics feels outdated and something that would be necessary on old forum software.
멋지네요! 여기까지 답변해 주셔서 감사합니다. 이 주제를 시작해서 사람들이 이에 대해 어떻게 느끼는지 알아볼 수 있어서 기쁩니다.
제가 틀렸을 수도 있지만, 최근 몇 달간의 제 경험에 비추어 볼 때 Support 카테고리는 현재 우리가 가진 다른 카테고리들과는 다르다고 느낍니다. 사람들은 문제를 바로 해결하러 옵니다. 그리고 거의 항상 그 문제는 해당 사용자의 고유한 상황에 매우 구체적입니다. 주제가 합리적인 시간 안에 해결되지 않으면, 그들은 흥미를 잃고 다른 곳으로 떠나거나, 인내심을 잃고 다른 주제에서 다시 질문합니다. 그 사이 지원 카테고리는 답변되지 않은 질문들로 가득 차게 됩니다. 이후에 온 다른 사용자들은 자신만의 약간 다른 질문을 하기 위해 그들을 다시 올립니다. 하지만 이런 질문들은 새 주제에서 하는 것이 훨씬 나을 것입니다.
이는 #support에서 다른 카테고리들과는 다릅니다. 다른 카테고리에서는 열린 주제(Open-ended topics)를 허용하고 장려합니다. 사람들이 #support에 다른 카테고리에 속하는 주제를 게시할 때, 예를 들어 실제로 Contribute > Feature 요청인 경우, 우리는 그들을 이동시킬 수 있습니다. 또는 플러그인 생성에 대한 도움이 필요한 경우, #dev로 이동시킵니다.
그러므로 어떤 방식으로든, 답변되지 않거나 논의가 흐지부지되는 Support 주제는 최종적으로 해결될 수 있도록 후속 조치가 필요합니다. 일주일 또는 두 주 후에 답변을 추가하고, 마지막 응답 후 30일 후에 닫도록 설정하는 것이 이것이 일어나도록 보장하는 합리적인 방법이라고 생각합니다.
여기서 제가 듣고 있는 것은, 우리가 주제를 자주 이동시키기 때문에(그것은 타이머를 제거해야 함을 의미합니다), 모든 Support 주제를 30일 후에 자동으로 닫는 것이 결국 올바른 접근 방식이 아닐 수 있다는 것입니다. 하지만 여전히 모든 Support 주제를 최종적으로 닫는 것을 목표로 해야 한다고 생각합니다.
그래서 지금은 자동 설정을 꺼두되, 제가 적절하다고 생각하는 경우에만 타이머를 추가할 것입니다. 만약 제가 타이머를 설정한 주제에서 타이머를 설정하지 말았어야 한다고 생각하신다면, 그 이유와 함께 알려주세요.
I tried out the data explorer query and see that in the last four weeks we’ve collectively moved 53 topics out of Support into other categories. That is enough that it would definitely be inconvenient to have to ask a moderator to remove the automatic timer.
So back to the drawing board on figuring out how to ensure that everyone who posts in Support gets a timely response!
Looks like adding the timer cleared the category setting when topics that have been marked solved will be auto-closed. I set that to 72 hours now because I don’t recall exactly what it was set at before.
As a user, I’m always frustrated when I come across an issue I have, find a related topic I want to post in, and notice it is closed (not talking about solved topics).
Then I have either to contact the staff and ask them to open the topic or create a new one when the original topic would have been the right one to reply to.
I’m not speaking specifically about meta, but in regard to my user experience in other forums where I experienced that.
감사합니다! 해결했어요. 날짜나 월이 아니라 시간 단위로 지정되어 있어서 계산기를 꺼내야 했어요. 720시간이네요!
수정: 아, 그리고 직원 작업 로그를 확인할 수 있다는 걸 방금 기억났어요. 자동 닫기 타이머를 추가할 때 720을 제거한 기록이 남아 있긴 해요. 하지만 변경 사항을 저장할 때 UI에서 경고가 나오지 않은 건 좀 이상하네요. 이 문제를 Contribute > UX 토픽에서 지적했습니다.
That’s happened to me too. I usually start a new topic with “Continuing the conversation from [closed topic]…”
Sometimes I just have a thought or suggestion to add, rather than further questions – but I imagine the priority for support staff has to be the visibility of new questions. Feels like that could be hard to ensure if solved topics were perpetually left open for additional posts.
Virtualmin - Virtualmin Community is an example: all topics are automatically closed after two months, regardless of their content, and if they are solved or not.
To wrap up this conversation.. thanks for all the input and helping think this through.
For Support topics I remain convinced the goal is to close them within a few weeks in nearly all cases. It’s the only way to be sure that everyone who is asking for help is being answered on a timely basis. Without that, people are going to start losing confidence and will look for answers elsewhere.
I have noticed that if there is a reason to leave a topic open then typically it is also suitable for moving to another category.
But I agree that the idea of automatically closing Support topics 30 days after last reply is not going to work for us. We want to make sure they are actually resolved, and avoid a situation where the category is full of unanswered or only half answered questions.
solved topics).