WordPress.org support forums: more ideas for improvement
A few days ago, I wrote a post pointing out the potential value of adding a “support expectations statement” to the WordPress.org support forums. We’re huge fans of the work the dot-org team has done, as we noted in that article, but it didn’t stop us from thinking about other ways the dot-org forums could be improved.
As someone who does a pass through The Events Calendar forum each week, and having compared it to the bbPress install we’ve got running to power the forums here on the Modern Tribe website, I came up with a short “wish list” of the features that would help improve the support experience from both an admin and a user perspective:
- The ability to close threads. When a thread is either stale (no response from the original poster) or resolved (the original poster is satisfied and has confirmed as much), there should be a way for plugin authors and/or the original poster to close that thread so it cannot be hijacked by another user down the road. We constantly find situations where a thread that hasn’t been touched in months — usually relating to an outdated version of the plugin, and more often than not “Resolved” for the user who first posed the question — is brought back to life by a user who believes their problem is related to the original issue. It may well be, but for organizational purposes it’d make much more sense to make this second user log their issue separately.
- Marking an answer. How great would it be if plugin authors and/or the original poster could mark an answer as the correct solution? We’ve had significant success with this here on the tri.be site: once a thread is resolved we can set the answer so it appears in a green “Answered” box on the frontend, and so anyone who visits that thread down the road will know immediately where the solution can be found. On dot-org, where we’ve recently had a handful of threads that run 3-4 pages of discussion, an Answered option would save everybody some time and would generally keep things more organized. (As it stands now, if I view a thread that’s marked “Resolved,” I’d assume that there’d be something pointing to the resolution…but once I click into the thread I’m on my own to figure out which answer is the right one).
- Success isn’t always defined by “resolved threads.” From a plugin author’s perspective, we would get more value out of seeing a tally of “closed threads” or “unaddressed threads” count on the homepage than from the “resolved threads” count that appears currently. Almost weekly I see situations where a user posted a thread and, despite our follow-ups, never came back to engage beyond posting that initial message. This thread isn’t technically resolved; but, since the user is no longer seeking support, it also isn’t still an active thread that should count against this “resolved” count. What we’ve gotten in the habit of doing is going back through all older threads from the past 2 months and marking those where the user never followed-up as “Resolved”, with the assumption they either found resolution on their own or moved on to another solution. But this isn’t ideal, isn’t accurate and isn’t a very good use of anybody’s time. If we could see closed threads (tying back to #1 on this list), we’d be able to more accurately track those that had come to a natural conclusion. Alternatively, seeing a count for “unaddressed threads” would immediately show our support team what needed addressing and would show potential users how many/few users a plugin author actually does follow-up with.
- Additional contact options to help users. Imagine you’re doing support for a plugin, and there’s a vocal user who is obviously frustrated. He’s having problems getting your plugin working, but when you respond to his thread he doesn’t follow-up…maybe he forgot to subscribe to email updates or perhaps he’s just moved on. Wouldn’t it be nice if you could contact that individual directly, either through a private message system built into dot-org or through old fashioned email? This wouldn’t need to be publicly available information; it could be visible only to plugin authors, and could even be something users need to opt-in to if they want to make themselves available that way. But for us — in situations where we either want to follow-up to make sure someone got their problem sorted, or so we can contact the user privately to request a copy of a conflicting plugin/database dump/etc — it’d allow us to be more proactive than simply saying, “Email us when you get this.”
- “Not a Support Question” threads. Including these in the broader list of active threads without any indicator that they’re not support-centric is misleading. Why not include some bracketed text in the broader list that says [Not a support question], the same way [Resolved] appears when a thread is finished? This way the support team could view the list of active threads and be able to prioritize what’s support versus what’s not. As it stands, when I view the list and see 20 new threads, there is no way of knowing how many of those are actually support questions until I click into them individually.
- “Slow down, you’re moving too fast”…really? This is the lowest priority issue, and it’s more a gripe borne of impatience than anything else. But when there are a bunch of threads that merely require a one or two word response — “Great!”, “Thanks for confirming,” etc — bbPress limits you in trying to respond to those quickly; the dreaded “Slow down” message appears (with a link taking you back to support that actually leads someplace completely different than where you came from). This is probably to safeguard against spam…but is someone running support really at risk to spam their users? Why not automatically allow all plugin authors to ignore the bbPress 30 second post throttling limit by default?
We love the dot-org forum and have built some awesome relationships with our users there. But we also know that there are areas it could be improved to help make our lives easier, and to allow us to provide better support to more users in a more timely fashion. And since supporting a free plugin doesn’t always have immediate financial payoff, the need for streamlining the process becomes even more important.
If you’ve got a plugin up WordPress.org, what are your thoughts? Did we craft this list in a bubble (which is very possible, given how support needs differ from company to company)? Or do you share any of these wishes / have your own to add? We’d love to hear thoughts in the comments.