Item1559: Support system used as a bug tracker too often

A lot of reports I see there are plain bug reports. There is no hint on an extensions home page how to file a bug. So it is no big surprise that support requests are bug reports actually. In fact, these two systems overlap here in their purpose.

How do we resolve this?

-- MichaelDaum - 03 May 2009

We have the same problem the other way

Too many people ask support questions on the Tasks web.

and I have same problem on my Motion project though the user interface I have made is quite different.

To be honest - I do not think there is a clear solution to this.

The more guide text you write - the less people read it.

Fact is many people are not sure of a problem they have is their own fault or a bug in our software. So they make a qualified guess.

When I look at the Support web home I fail to see how anyone can write it more clearly than we have already done.

But maybe someone has a very new cool idea how you guide people through a set of questions that make them end up the right place.

-- KennethLavrsen - 04 May 2009

we have a field in support that can mark the topic as "file this as a (bug) task"

can we construct a "one click" solution to move topics between the support and tasks webs?

to some degree, it seems inevitable that bugs or support questions will get posted in the wrong area. people may think they are doing something wrong, and post a support question, only to be told that it's a bug.

and, shouldn't this question have been posted in development?

-- WillNorris - 04 May 2009

The project should be lenient on users -- be happy they file anything at all! By default, I expect more people would file support questions, expecting the person providing the support to turn them into tasks if answering the question requires some work to be done.

-- IsaacLin - 05 May 2009

People don't know where to ask their question and how to classify it. People don't use the webs Support, Tasks and Develop as intended. And there is a reason for that.

A user having a problem does not know if it is him using the software wrongly or is it the software that has got a plain bug or whether it is a feature that nobody has thought of before and the software, while being correct, simply doesn't cover this use case.

By nature, when a task or a question arises it is unknown how to classify it. It gets even worse as Tasks and Support are two totally independent applications with net data (the topics) being separated physically. How could you possibly decide where to create it?

Tasks and Develop also overlap, but differently. As Will pointed out, the wish to "move & convert" an Item topic from Tasks to Develop in order to make it a proper Proposal topic arises as often and for the same reason as a Support Question should be changed into a bug report.

The "which web" question should go away. We are not constraint by physical racks like a librarian. This is a virtual world. The logical consequence is to merge the webs Support and Tasks (maybe Develop as well) and create a proper taxonomy covering these topics. This will also allow to classify a topic as a "support topic" as well as a "bug report" at the same time.

And what you see here isn't a unique problem to foswiki.org.

I'd normally solve this problem using the ClassificationPlugin and the WikiWorbenchAddOn. However both rely on technology that are still in T* namespace, besides not being published yet.

-- MichaelDaum - 05 May 2009

There are also advantages ín having very separate applications.

For sure I would not want to merge Tasks and Development feature proposals. The two applications are very very different and I would like to maintain a "pain-barrier" between them so we do not get swamped in uncommitted feature proposals that people just ignore.

With respect to Tasks and Support, the common application makes more sense. But merging the two and seperate the two by a form field is not going to prevent support questions to mix with tasks.

People still has the same basic problem that they cannot understand the difference between support question and bug report.

We should learn a little from our own experiences. We had a major issue with development related bugs being mixed up with tasks. The problem was reduced when I removed many of the values people had added to the Applies To field.

But I still have to review the non Core/non Extensions bugs monthly and I always find bugs that we all have missed because of a wrong classification. And it is experienced developers that get this wrong.

If we also add feature proposals and support requests to this application things go even worse. Then we get even more noise in the Tasks web and even more bugs that none sees.

I'd rather make a small wizard app that helps the reporter to the right place by answered 2-3 small questions.

Our Tasks web also need a workover. We have a SVN range field which is unused and wrong.

Code base is constantly left untouched which is OK because we do not use it.

And the important TargetRelease and ReleasedIn fields are constantly ignored giving me white hair as release manager.

If we add more fields for feature proposals, and support questions we will end up with a nightmare form.

I cannot say how the new unpublished extensions can help. That I would need to see demoed first before I will try to support or dismiss it.

-- KennethLavrsen - 05 May 2009

Can't see this discussion leading to anywhere.

-- MichaelDaum - 25 Mar 2011