I wanted to check in with you all about an experiment I am trying. Some of you likely have better community memory than I do, so please educate me!
I have set the Support category so that topics are automatically closed 30 days after the last reply. This seems appropriate given my recent experience in the category. By then topics have been resolved or the person asking has moved on. Others with similar questions can start new topics particular to their situation.
For the last several months I have been triaging older Support topics that have gone unresolved, using this filter in my sidebar. In many cases topics actually get resolved fairly quickly thanks to very attentive and helpful members who answer questions. Sometimes topics do need a nudge after a week or two in order to check in with the person asking for help to see if their issue has been resolved, and to ask clarifying questions that might help them along (What are the repro steps? Did you use official install instructions? Does it work in safe mode? Etc). When I do this I will usually add a topic timer to close automatically 30 days after the last reply. If the person or another member in the community doesn’t respond within 30 days then I think it’s perfectly fine to let the topic close automatically.
However there are also cases when it makes sense to move topics from Support to another category, and I have been doing that too. For instance:
→ Community = open ended community building questions
→ Dev = customization, creating new plugins, etc
→ Feature or UX = feature requests or user interface improvements/fixes
→ Bug = bug reports
By setting topics in Support to automatically close after a month vs doing it manually, I am saving myself some time because currently using the admin wrench to do that is a bit cumbersome. It’s several clicks away!
I’ll check back in in a month or so to decide if we want to keep this setting enabled or if another approach might work better.
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.
Awesome! Thanks for all the replies here. I am glad I started this topic, to find out how people feel about this.
I may be wrong about this, but my own feeling from my experience in recent months has been that the Support category is different from the other categories we have currently. People come wanting to solve a problem right now and nearly always the problem is very specific to their own circumstances. If the topic does not get resolved reasonably quickly then they lose interest and move on, or become impatient and ask again in other topics. Meanwhile the support category can become littered with unanswered questions. Other later travelers then bump them to ask their own slightly different questions which would be better off in a new topic.
This is different from the other categories where we do allow and encourage open ended topics. When people post topics to Support that belong in other categories, e.g. because they are actually a Feature request, we can move them. Or if someone is looking for help with creating a plugin, we move it to Dev.
So one way or another Support topics that go unanswered or where discussion peters out need to be followed up on so they can be brought to resolution eventually. I think adding a reply a week or two later and then setting them to close 30 days after the last response seems like a reasonable way to make sure that happens.
What I am hearing here is that the automatic closing of all Support topics 30 days later is probably not the right approach after all, given that we often move them which then means we have to remove the timer. But I still think that we should aim to eventually close all Support topics.
So I’ll turn off the automatic setting for now but keep adding the timer in cases where I think it makes sense. If you notice I have set a timer on a topic where you think I should not have, let me know and the reason why.
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.
Thank you! Fixed it. It’s specified in hours not days or months, so I had to pull out the calculator. 720 hours!
Edit: also, just remembered I can check the staff action log. It did record that I removed the 720 when I added the auto-close timer. But that it did not warn me in the UI as I saved the changes is a bit strange. I pointed out this issue in a UX topic.
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).