We spend a lot of our time in the Drupal.org issue queues, working on bug fixes and adding new features. It’s an okay tool for organizing development, and we’ve grown used to its quirks by now.
Users also try to use the issue queues to receive support, with more or less luck (typically, the bigger the module is, the less luck they have).
And while it’s great to have the support request category to reclassify confused bug reports or already implemented feature requests, as an actual tool for support the issue queue is terrible and it hurts the community.
The problem
The main problem lies in its name: it’s a queue, not a knowledge base.
Support requests get in, they get answered, they get out.
People rarely search for existing support requests, preferring to ask new questions (and to be honest, the advanced search interface is not among the friendliest), and maintainers often just repeat the answer. If a question is common enough, a documentation page will be created and referenced as the reply each time.
Of course, drupal.org users can only edit their own posts, so an answered question in the issue queue cannot be updated or expanded by others, allowing it to grow stale or incomplete over time.
The issue can also be hard to scan because of other replies (frequently unrelated to the main problem). Those replies are often filled with bad advice (“Sure, no need to use i18n, just add a t() around that variable!”), but there is no way to separate good answers from the bad ones.
Finally, each issue queue is a silo; there is no way to view support requests across all projects, which frequently puts support solely on the shoulders of the maintainers.
All this causes frustration in the users who have a hard time getting support, while still spending valuable maintainer time which could have been spent on bugfixes instead.
Q&A style support
A Q&A site such as Drupal Answers provides obvious benefits:
- Powerful and easy to use search.
- Questions have clear tags, allowing them to be found more easily
- Answers can be voted up and down, allowing bad answers to be buried and good answers to be singled out. The best answer can then be accepted by the user.
- Questions and answers can be edited by the community, allowing them to be expanded and kept up to date.
- The karma system motivates users to increase their activity in order to gain recognition, and later trade that karma in for faster support (“featured questions”) if needed.
All this together provides a superior support environment with many different people providing support for the same topics and projects.
Still, not every kind of support is fit for a Q&A format, which is why Drupal.org forums still have a place in the world, allowing such topics that are explicitly marked as offtopic by Drupal Answers:
- Comparison between Drupal and other CMS’s, blog software, or similar software
- Requests for tutorials, and other online resources
- Requests for writing code from scratch*
- Building a site from scratch
- Implementing a functionality, or a layout seen in a site, for which only a screenshot or a site URL is provided
Of course, encouraging (and contributing to) clear module documentation on Drupal.org is still essential and prevents many support requests from occurring in the first place.
Implementing the idea
This is why we’ve stopped providing support for Drupal Commerce and Commerce Kickstart in the Drupal issue queues , instead pointing users to the Q&A section on drupalcommerce.org.
I believe other modules and their users can also benefit from explicitly pointing their users to a Q&A site such as Drupal Answers.
Thoughts?
Bojan Živanović 
There was a big discussion brewing last year: https://drupal.org/node/1236290?page=1
A course of action was decided upon and chx is going to recheck on the progress on his birthday. I guess his frustration uttered in #52 won’t go away. 😦
I think going this route for a big module (suite) like Commerce is a good way to go as it is something actually manageable with positive outcome at hand. The olden way might be manageable for smaller modules but overall I agree that support requests are a something of a monkey-wrench in the issue queue.
I was a part of that discussion, but it mostly centered around killing Drupal.org forums in favor of Drupal Answers (even though the Q&A format is not a complete replacement). It didn’t touch the problem of issue queues at all.
I, for one, am in support of the q/a style. However i am not in support of module maintainers running off and setting up there own system away from d.o. I personally think even the commerce one should be moved back. I never used the ubercart forums that were offsite and I don’t want to have it fragmented again. We need something robust and homegrown to reflect the size, diversity of the community. Something that is modern and user friendly like the drupal stack exchange site but with more community support and oversight.
I don’t think the general drupal community is interested in building reusable Q&A clones, you’d have a few by now if it was. That’s why I was unhappy about leaving Drupal forums active because “someone, someday” will improve the support options on d.o.
Nobody will, because it needs to be paid for and project managed.
Great write-up, Bojan. Moving support out of the issue queue has done two great things for us: 1) improved our ability to provide support and cross-reference it with all the other knowledge on DrupalCommerce.org and 2) made the issue queue a much more productive environment for actual module maintenance.
That last one is the biggie for me. When I go to my module’s issue queue, I should be able to quickly sort through what needs to be done and close issues out ASAP. With open ended support requests, you never really get to achieve this, and as Bojan mentioned, you end up with the same questions over and over because most people just don’t know to search for “closed” issues.
Re: Nigel – I’ve gotten that both go rounds now w/ respect to Ubercart.org and DrupalCommerce.org, but a project that needs such a space can’t wait on an abstract solution to be developed that serves the needs of a large project and every thousandth’ stand alone project as well (much less Drupal itself!). I don’t think we need every piece of information to reside on drupal.org – no one argues that would be a helpful way to foster the development of Drupal based products – but perhaps we can start thinking more about reusing content across domains via decent APIs. With Drupal 8 and REST in core, this may in fact become easier.
Anyways, trying to move everything back on d.o would accomplish nothing but put us back in a spot of having a poor interface to provide support and no actual resources to commit to updating d.o to actually work for us. That’s a full time job that many people would have to be committed to. That said, StackExchange has an API, right? Perhaps we can simply integrate that onto our domain in the future… but it’s still a future idea that requires cold hard cash / time to become a reality, and the needs of today for projects like ours remain to be met.
Interesting topic. I think the issue of support is a general problem so some type of supported resource beyond issue queues is likely a good idea (and I dont mean financially by “supported”, that could be included but I mean broader community support). I’ve notice more and more comments on my video tutorials of being asking basic questions that are easily answered by a google search. On a few occasions, I get direct emails asking me. I like to help people but sometimes it’s frustrating if they aren’t trying to help themselves first.
As an aside Bojanz, I find it icon to blog about Drupal on the wordpress platform 🙂
1. Context and Success
Excellent customer support wins. Support has to be an integral part of the entire product, project, community, and all workflows. Independent platforms certainly work, but won’t reach the required level of inclusion, maturity, and quality. If you really care for support, think bigger: Why are our thoughts limited to external platforms? Why doesn’t the product have support built-in?
2. Goals
The immediate goal of customer support is to provide answers. However: The strategic target of support is to improve the product and solutions. Skip this actual underlying goal and any quantity or quality of support will fail.
~6 badass questions on the same topic must trigger a critical feedback loop to product owners and engineers. If that is not the goal of support, why do you attempt to provide it in the first place?
3. Integration
The vast majority of skilled contributors does not participate in the current, external platform. Field/domain experts are not able to approve answers that are technically correct, without gaining “reputation” first. Identity and authority has to be a fundamental part of a support system. Connect it, or loose the connection.
There are industry standards for this: http://networkedhelpdesk.org/
4. Growth
You want a deep connection from support to engineering. People working on support questions have a good and grounded understanding of shortcomings in your product. Fail to establish and ensure that connection and involvement, and your product will not improve in areas that matter.
In short, I agree with the symptom. But I believe our current answers are short-sighted and will make the support situation only worse. We are replacing one evil with another, without realizing the consequences of our actions.
Thanks,
sun
Thanks for the great comment. It’s worthy of a blog post of its own.
I agree with each one of your points, though I also understand that it would require dramatically improving / reworking drupal.org, which is something the community isn’t able to do at the moment, since it requires major funding and coordination. My proposed solution is just a band-aid, allowing us to direct to a better channel today, while planning for the hypothetical tomorrow.
If there were simply a “how to…” tag that could be applied to informative posts in the queues that explain how to do something, then these could be selected (for example in a view) and listed or linked to on the module home page so that users could more easily find these commonly sought after solutions (when insufficient documentation is available).
I think this works very well and makes perfect sense for the larger, well-used modules. But for lesser used contrib modules, using the issue queue for support requests is often the only way you can get help with an issue, especially since documentation on many contrib modules is non-existent or extremely limited.
Also, sometimes it’s not clear whether something that isn’t working as one expects is just a “how do i..?” vs something that may indeed be a bug.
The only thing I don’t quite understand is why did you decide on a custom Q&A solution, instead of using the stackexchange platform (for example: drupalcommerce.stackexchange.com).
Other than that, the immediate benefits of having a separate Q&A site/section are pretty clear IMHO, but sun’s comment is great food for thought on the big picture.
Just wanted to note that we do have plans for a better support system on D.o. We were about to start working on this last year, held a BOF at DC Munich dedicated to this topic. Unfortunately D7 upgrade forced us to postpone the project. I hope we can get back to it once the upgrade is finished.
IMHO … moving to a QA format separate from the issues queue is a good idea … but moving it off to a more mature platform like stackexchange is not as good an idea. .. Why? because even half-ass’d integration with project and issue queues would be more valuable then a points system (at least initially).
Point in case: I am having an issue with a Commerce add on module not working the way I expect it too. I don’t think it’s a bug but I start looking on the related queues anyway, turns out it’s an open issue with Rules and Drupal Core. I usually search multiple issue queues before I post a “support request” issue. Having a separate system makes it harder for the users to do their own due-diligence before posting a question.
Even half-ass integration with Projects/Issues on D.O. would allow:
– views like “30 unanswered questions tagged Rules”, “200 questions answered questions” on Project Pages
– Turn this question into an issue button
– Close this Issue and create a question button (or issue status)
– Advanced search with Search questions and Issues
PS: Commons plus https://drupal.org/project/commons_correct_answer is pretty good.