592533 - Need a "SUPPORT" resolution on the BMO resolution set

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[cmtalbert]

We encounter a lot of issues that come into BMO that turn out to be support requests. Unfortunately those are dealt with by marking them as INVALID which is the same resolution that truly invalid requests are marked with.  By marking these with a support resolution, we can analyze these bugs and provide a better user experience as well as aiding the support and triage team to find issues and tie bugzilla in better with sumo.  More details are available on bug 444302.

Comment 1

[:glob ✱]

done.

Comment 2

[:glob ✱]

sorry, disabled for now.

Comment 3

[Andre Klapper]

I am not convinced.

I (co)maintain several Bugzilla instances out there and generally I prefer to keep the amount of available resolutions in Bugzillas simple and small.
 
If it's just about the "INVALID" sounding bad and negative, it could either be renamed to "NOTABUG". I'd generally recommended anyway to actually explain why you close the report as INVALID/NOTABUG/SUPPORT ("it's not a mistake/bug in the codebase, but a configuration/support issue" in words that are understandable to normal users).

My first idea to avoid closing the report as INVALID was to instead move the complete report to a "sumo additions" product in Bugzilla, get it processed and added to sumo, close the report as FIXED (no more INVALID) and tell the user "Thanks to your report we document this now in our support section, here is the URL for it, you rock." which provides a more positive experience.

However as I was told today, support.mozilla.org (in short: sumo) receives about 2000 (?) questions per week, plus sumo has a "I have this problem too" checkbox to know how many users are affected by a problem, plus access statistics and helpful/unhelpful voting statistics. 

A misfiled support request in Bugzilla does not tell you whether the problem is common and should really be covered in sumo. Plus it might be covered already there anyway, so not sure if sending an email everytime a bug report is closed as RESOLVED SUPPORT (as proposed in bug 444302) creates more value than burden.

If it's really about analyzing which misfiled support requests in Bugzilla are common, a keyword "support" should also do it to query among the RESOLVED INVALID ones.

Your comments are welcome.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Ah, I missed this, sorry.  I do think this would help.  It would be easier to mark, to search for and to expose than adding a keyword.  And it would also be more polite to the users -- while I like Andre's idea of moving to a "SUMO" product that will not be scalable for BMO and the bug reporter won't understand it as well.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

How do you think it would be best to implement this? I can bring it up on the bugmasters mailing list, or somewhere else, if you think it needs more discussion. 

We would need to change the docs here,

* https://bugzilla.mozilla.org/page.cgi?id=fields.html
* https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla
* https://wiki.mozilla.org/index.php?title=QA/Triage  

and then check various other pages to add in the Support flag.

Comment 7

[David Lawrence [:dkl]]

(In reply to Liz Henry :lizzard from comment #6)
> How do you think it would be best to implement this? I can bring it up on
> the bugmasters mailing list, or somewhere else, if you think it needs more
> discussion. 
> 
> We would need to change the docs here,
> 
> * https://bugzilla.mozilla.org/page.cgi?id=fields.html
> *
> https://developer.mozilla.org/en-US/docs/
> What_to_do_and_what_not_to_do_in_Bugzilla
> * https://wiki.mozilla.org/index.php?title=QA/Triage  
> 
> and then check various other pages to add in the Support flag.

From a technical standpoint we would just need to re-enable the resolution (it's there but off for use) and update the fields extension template explaining what it means. Not much effort really. Are we sure there will be no backlash?

dkl

Comment 8

[Mike Hoye [:mhoye]]

I think the right question is, is the expected benefit we'll derive from this worth  any backlash we might receive, and I think that put in those terms the answer is pretty clearly "we should totally do this".

Let me touch base with SUMO just to let them know we're making the change, since this touches on them as well, and they may have something to say about the process, and I'll come back with news.

Comment 9

[:glob ✱]

while this resolution may help clarify the true state of some bugs, we're putting a freeze on the current statuses and resolutions, due to the impact changing these will have on systems which integrate with bmo (such as dashboards).

Comment 10

[cmtalbert]

That makes sense. We will have to find other ways of tracking support issues via other metadata instead then.