5

Courtesy of the 'What types of support questions should be allowed?' thread:

Technical Support Only
Stack Exchange should only be ONE of the support options listed on the product's main site. Make sure you have other resources for support apart from Stack Exchange. Issues like bug reporting, feature requests, generalized discussions, and specific customer support issues do not fit into our Q&A model, and should be quickly closed by the community.

There seems to be an increasing volume of bug reports on the site at the moment and none of them are being closed, so perhaps it's worth clarifying the community consensus.

Maybe I'm in a minority but I'm all for closing bug report questions and suggesting that they're redirected to the product devs. In some cases if a non-commercial addon has been abandoned then I don't see why people shouldn't seek help here, but (for me at least) the site's rapidly going to lose its appeal if the recent questions list mostly consists of variants of 'Feature X from Product Y doesn't work'.

Thoughts?

3 Answers 3

6

This is already quasi policy, so…

Bug reports should be redirected to the correct support forum, and closed as off topic here.

Stack Exchange works really well for technical support, as long as you're not trying to outsource your entire customer support channel to Stack Exchange. There's a good meta post covering the issue below, and the the top two answers are worth reading:

Is it okay to use Stack Overflow as the support forum for a product or project?

4

I agree, the wealth of these questions irritate me. I have from the beginning been of the opinion that developers proffering EESE as their official support route is a bad idea, and will ultimately fill the site with noise. This is exactly what we're seeing with the release of Assets 2.0, and P&T's move to point all support requests here.

I've been going through and closing feature requests and merging identical bug reports where I can. Since this is now the only venue P&T is offering for new support requests, I hesitate to delete the bug reports, but ultimately I think they should go.

If more devs go the route of sending their customers here as front-line support, I fear this problem will only grow. A frustrated add-on user doesn't care what the intent and guidelines of StackExchange are - they will treat this like an official support forum and post any problem they have, regardless of it's nature or answerability.

2

I'm in two minds about this. While I realize Stack Exchange say these types of questions don't work, and from the start people have been clear they don't want to see bug reports or feature requests here, I've still yet to see what the actual problem is.

Obviously it has been stated by Robert et al that these questions don't work on Stack Overflow (per referenced MSO threads), but this forum is different to Stack Overflow, and I don't believe SE have any other forums even similar to EE Answers (other than Wordpress and Drupal, but those don't have anywhere near the percentage community support as EE Answers).

Let's take a look at a couple of recent questions:


A bug report: Assets 2.0.2 Fatal error

TL;DR: A PHP error displaying on pages after upgrading to latest version. Answer: Fixed in next release (with version number). This benefits the community, because anyone googling that error, or searching SE will find the solution. Great!

In other situations like this, I have seen developers post a comment asking for the OP to follow up via email, then the solution has been posted as an answer. As long as the questions are being followed up and answered (following the Q&A format), that seems fine to me.


A feature request: {exp:assets:files} limit parameter not limiting the returned files

TL;DR: Trying to use tags in a certain way, not working. Answer: Not possible yet, will be supported in 2.1 release. This also benefits the community - it can be found via searches, and also referenced if the same question happens to be asked again. Again, it also follows the Q&A model perfectly. Great!


I'd like someone to point out what is so particularly "on the slippery slope to the site failing" about these questions. As you say, we've been getting more of them lately, and yet our site statics keep going up and up (and compared to other SE betas we are extremely successful). The main argument I've heard so far is that people don't like seeing them on the front page / recent questions list. However, I think that is a little short sighted - you're never going to be able to grok every question on the front page. Just look at the Stack Overflow front page - most of the questions there I don't have a clue about, and yet the site is wildly successful. You can set favorite and ignored tags if you don't care about certain questions.

The other main argument against these questions seems to be that Jeff Atwood says it's not allowed on Stack Overflow - but as I pointed out earlier, this site is completely different from Stack Overflow (otherwise we wouldn't need it in the first place), so it should have different goals, and therefore different rules.

At the end of the day, I want this site to succeed, and this is a community decision. I think providing official add-on support here is fantastic, and will lead to a hugely successful, popular site and a great resource for the EE community. So before we start pushing add-on developers and users away by abruptly closing questions, I'd like to see some strong evidence/arguments for why people are against this.

6
  • 2
    But these question become completely moot in a matter of days, when these bug fixes are released. If the site becomes too noisy with bug reports and feature requests, then the knowledgable people who come here to answer the tough and/or interesting questions will disappear, as they will become tired of filtering through all the cruft. That, and there are in fact polices we have to follow here. We have been welcomed to have a space on the SE network, where they have a lot of experience doing this. We should take their policies, unwritten or written, seriously.
    – Derek Hogue Mod
    Commented Jan 19, 2013 at 23:17
  • 2
    I don't think I've ever suggested that bug reports equate to the impending doom of the site but I am of the view that if you're using a commercial product which has a bug then the best approach is to contact the dev and wait for a patch. Why add noise here? If an issue is so prevalent that there needs to be some kind of public notice on the subject the dev has plenty of other options for getting that info (or a fix) out there. It also seems unfair to me that volunteer mods are having to deal with what's otherwise the work of paid customer support agents (filtering, merging tickets etc).
    – Dom Stubbs
    Commented Jan 21, 2013 at 18:10
  • 2
    One of my main concerns is making it easy for users to identify what should and shouldn't be posted here. How about we have something on the "how to ask" page (and use as a standard response to close bug questions) like: If you are seeing PHP errors, and can identify which add-on is causing them, please contact the developer directly in the first instance. This leaves SE open as a secondary venue, but should eliminate 80% of the bug noise here. Also it will not alienate new users who may not be able to tell the difference between bugs and their own ignorance/misunderstanding.
    – Adrian Macneil Mod
    Commented Jan 24, 2013 at 13:42
  • For example, I think that would be a good template response to close this question which was just asked: expressionengine.stackexchange.com/questions/5344/…
    – Adrian Macneil Mod
    Commented Jan 24, 2013 at 13:43
  • I like this idea Adrian. Care to craft a starter guideline blurb in a new meta thread, maybe as a community wiki?
    – Derek Hogue Mod
    Commented Jan 24, 2013 at 19:39
  • Sure. I'll do some research into which bits of the FAQ and How to Ask pages we are expected to change, and start a new thread.
    – Adrian Macneil Mod
    Commented Jan 25, 2013 at 2:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .