Opened 10 months ago

Last modified 7 months ago

#7161 new enhancement

Remove auto-closure from support from threads and add warning if thread is old instead

Reported by: alh0319's profile alh0319 Owned by:
Milestone: Priority: low
Component: Support Forums Keywords: close


Support forum threads should not close automatically to replies. There are multiple use cases where it is necessary to respond to an "old" thread, for example:

  • As a plugin dev, we forgot to subscribe to a plugin's forum and only saw support threads many months later. Currently, there is no way to provide assistance on these threads.
  • If a user requests a feature that is not currently available and you release it many months later, it would be nice to update their support request and let them know.

This was referenced as a footnote in #6722, but can be handled separately from changing time to edit posts. IMO, this is way more important.

In a conversation on post status @matt suggested removing the colsure completely and adding a warning instead:

Let's move away from auto-closing to just having a warning that you're replying
to an old thread

Change History (22)

#1 @sterndata
10 months ago

IMHO, this will lead to even more "me, too" posts or "I'm having a similar but completely different problem". A warning that this is an old thread will not stop such replies.

#2 @alh0319
10 months ago

Is that actually a problem? There are some cases where it makes sense to troubleshoot similar issues on the same thread.

Or if that really is a concern, what about allowing the original poster and plugin contributors to post after a certain amount of time but not other users?

Or giving thread closure control to plugin contributors?

#3 @sterndata
10 months ago

Yes, it's actually a problem. Based on my observations, multiple people jumping in on threads make it hard for the dev to solve any one problem and any solution confuses those with where the solution does not work because they don't have the same problem. I have no issue with plugin "staff" posting once the thread is closed, but no one else other than the moderators.

#4 @joedolson
10 months ago

Yes, that's definitely a problem. It would help alleviate it to give plugin authors the ability to close a thread. Though when you have thousands of open support threads, that would still be a pretty significant potential burden.

I think there should be a better way of handling closed support threads - it's a problem that auto-closed threads literally *cannot* be re-opened because they'll just auto-close again. But I'm dubious about just leaving them open.

At the least, I think that removing the auto-closing *must* come with some ability for plugin authors to close threads; otherwise this would become totally unmanageable.

#5 @alh0319
10 months ago

Most support ticket systems have a "reply and close" option. I think many plugin developers with a large volume of support tickets would be familiar with that. We deal with a lot of support tickets via Zendesk and control when they close on a per-ticket basis, and I don't think it's a significant burden. Honestly, giving plugin contributors the ability to close threads would be nice because they could close them before the six-month mark if they want.

I discovered 12 support tickets yesterday on a plugin I had not realized we were not subscribed to, which I want to at least comment on to see if they still need help. I can't do this. It's a frustrating experience for me and clearly a poor user experience for the original poster or anyone else who encounters that thread with a similar problem.

Another option might be to auto-close them but add a button that allows them to be reopened by plugin contributors that sets another six-month (or maybe a shorter time period) timeline before auto-close.

Last edited 10 months ago by alh0319 (previous) (diff)

#6 @sterndata
10 months ago

With respect to devs closing a topic, we see a LOT of user replies like "You closed this topic but it's not resolved." (They use "closed" there to mean marked as resolved, but it's a small difference to the user.) This will lead to more user anger and abusive replies and reviews.


#7 @fierevere
10 months ago

Old topics mostly attract spam, me-too-pile'ons and random replies,
its very rare when an actual reply is needed to something that has no activity for six months.

Current policy is to leave such topics closed, however, making an exclusion and manually reopen it at request can be made possible when the reasons for it are compelling (It can be discussed on Support team weekly chat, if needed).

#8 @fierevere
10 months ago

@alh0319 Also please note this important moment:

, topics are open for open source collaboration whenever they keep the activity, if someone has something valuable to add to topic - they can do so.

Regarding "closure" by plugin support reps, we can see a lot of "closures" after few days of inactivity or even after topic has been replied, this is counter-productive, even if topic wasnt actually closed (it was set as resolved and there is comment that issue is closed by support rep)

#9 @tnolte
9 months ago

I too have found myself, as a plugin developer, in many of the same situations as @alh0319 has mentioned. I have become a maintainer on 2 plugins and after following up sometime later with for example a big fix or feature implementation I am no longer able to update the thread with an update to properly inform people.

#10 @ramon fincken
9 months ago

Fully agree with @tnolte here

#11 @Otto42
9 months ago

  • Keywords close added
  • Priority changed from high to low

-1. I feel that if you don't respond to a thread in a year, then you're not going to and leaving it open only makes it easier for spam and other bad actors type of things.

Plus, and this is the most important factor, people use the "email me new replies" check box. It is actually the default setting. Meaning they get every reply to a thread they post. Sending them information like this over a year after the post is basically spamming their email. And that is simply something we cannot do.

#12 follow-up: @alh0319
9 months ago

@Otto42 they don't close in a year. It's 6 months, based on the threads that are closed on my plugin.

There are legitimate reasons for needing to reply on a closed thread that adds value, but I understand the concerns about possible spammy emails or unrelated conversations. That's why I think the ability to reopen the thread for limited people would be helpful.

#13 in reply to: ↑ 12 @Otto42
9 months ago

Replying to alh0319:

@Otto42 they don't close in a year. It's 6 months, based on the threads that are closed on my plugin.

I do believe it's 6 months after the latest reply.

Regardless of the various timing associated with the closure of the thread, my comments still stand.

#14 @jdembowski
9 months ago

The 6 months topic closure after last reply should remain because after that does not help the support topic owner, meaning the person who raised the support topic in the first place.

Most support ticket systems have a "reply and close" option.

I discovered 12 support tickets yesterday

This is part of the problem and I am not trying to be pedantic, honest.

The WordPress support forums are not a ticket system. We call them support topics because ticket systems have service level agreements (SLAs), moderation options for the ticket owner, etc. and support topics have none of that. If a plugin author or support person chooses not to even reply to a support topic, that's fine. See the part about no SLAs.

As I wrote, support topics belong to the person who raised it. Ownership and responsibility does not belong to plugin authors. By keeping a topic open or permitting it to be re-opened would not help the original poster. Neither does pile on replies from other people.

People can and should raise their own topic for their own problem. A person who still has the problem in a topic they raised that was automatically closed can and do raise a new support topic. They don't need a plugin developer to reply afterwards.

If a plugin developer wants, and many do, they can always refer support forum users to their own ticket system. In that event a stick post from the plugin developer and/or an update to the plugin or theme readme.txt file can facilitate that.

I think the plugin support link on the plugin page can have that opt-ed in to send the user to the developer's site for support but I am behind in my reading so check that too. I may be totally off on that last one.

#15 @zodiac1978
9 months ago

As already mentioned, this was already discussed in #6722:


The other point is that auto-closing after 6 months. Coming from the POV of a plugin support rep this can be a problem. Sometimes features are needing more time than 6 months and I couldn't inform user about the new feature. Creating a topic just to ping them seems a bit too much. The same applies for new/better supporters or later found solutions or plugin adoptions/sells and a new team re-checking old threads ...

How about allowing support reps and committers to open threads again or post in them even if they are closed, like mods/admins it can do.

Reply from @ipstenu

I mean... not to point a point to it, but if it takes 6 months to make a change, maybe you need a better way to track changes so you could tell people "We've put this on our to do list, but it may be a significant amount of time. Please follow our blog and it'll notify you when we get there."

Otherwise, from a user perspective, y'all ghosted people for 6 months. They probably moved on or gave up.

#16 @ramon fincken
9 months ago

About the ghosting Torsten: perhaps.

The issue is more that some changes are not significantly enough to fit in a persons spare time to fix/pick up within a few months. Lot of plugin developers are doing this in spare/free time. And some fixes/features just need more time because well.. they are big/complicated. Combined with the spare/free time aspect yes it could take months.

#17 @zodiac1978
9 months ago

@ramon-fincken I am just trying to add this part from the discussion from the other ticket here for completeness. You don't need to convince me, I am in favor of this feature. But obviously the advantages do not outweigh the problems that come with any approach, so I predict this will not happen.

#18 @ramon fincken
9 months ago

sure thing, I merely added it for others, hooking into your message :)

#19 @tnolte
9 months ago

I don't agree with the comments that the support forums aren't a ticketing system. They are very much presented as such when the response handling is prominently placed and featured on the plugin main page. This indicator is seen as an indicator of how well supported a plugin is. As others have already pointed out some of the items take time, and if some topics are old and we're never responded to, especially in the case of a plugin being taken over by a new maintainer then that visible "damage" can't be undone.

#20 @tnolte
9 months ago

I would very much request that this autoclosure length setting be allowed to be managed by the plugin author, just like one can do for GitHub Issues. I see no difference between the WordPress Support Forums and GitHub Issues.

This ticket was mentioned in Slack in #forums by trilos. View the logs.

7 months ago

7 months ago

I do not

  • agree to set the priority of this ticket to "low" as also security related threads are affected.
  • see the fact considered, that users are blocked for monitoring a thread by subscribing to it.
  • see any weight in a "spam attraction" aspect, this an general abstract problem which shouldn´t and cannot be solved in this context.

What about sending a reminder to the one who opened a ticket, asking for keeping it open?

Version 1, edited 7 months ago by TRILOS (previous) (next) (diff)
Note: See TracTickets for help on using tickets.