Bug 785842

Summary:	Better experience with private bugs
Product:	[Community] Bugzilla	Reporter:	Robin R. Price II <rprice>
Component:	User Interface	Assignee:	PnT DevOps Devs <hss-ied-bugs>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.6	CC:	esandeen, pspacek, sgreen
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-30 21:48:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Robin R. Price II 2012-01-30 18:39:09 UTC

I wanted to reach out to the BZ team to discuss private RHEL bugs.  A lot of points I am going to touch base on will be from a RHEL view point and not from a Fedora stand point.  If this is not the correct forum, could someone please forward me to the correct team to help consider my proposal?

As we continue to grow, Red Hat is striving to be the best customer/technical support solution on the market.  You can see a lot of these efforts in our Customer Portal system we delivered and the over all processes we have put into place.  I wanted to discuss private bugs to customers.

Putting BZ numbers in our changelogs and release/technical notes is not uncommon.  We do a wonderful job documenting the information in the errata summaries and brief overview of the BZ addressed in the chagelogs.  However, more and more bugs are becoming private.  This make sense because we want to protect customer data and information and even help our Partner's not share information to their competitors.  Some BZ's filed are set to private by accident or cloned with private comments all the way through.  Fine.  Makes sense.  It happens.

But what I wanted to highlight is, how can we take this information, and address it to the overall Access Denied messaged customers get. 

Example: While not logged in:
https://bugzilla.redhat.com/show_bug.cgi?id=711598

"You are not authorized to access bug #711598. To see this bug, you must first log in to an account with the appropriate permissions."

Could we make a response that can educate the customer as to why the possibilities the bug is marked private?  Could we drive them to go to the Customer Portal and contact support or their TAM for more information?  Could we at _least_ provide the Technical Notes in a public fashion?  This at least gives the customer something rather than a full, head on, brick wall stop.

Could we get private bugs that are resolved to show...:

1)  Link to errata link
2)  Technical Notes field
3)  Possible reasons why the BZ is private (Legal fluff here)
4)  For more, go to Customer Portal and contact Support/TAM

Could we get private bugs that are not resolved to show...:

1)  Bug Status
2)  Technical Notes field (they should be updating this now)
3)  Possible reasons why the BZ is private (Legal fluff here)
4)  For more, go to Customer Portal and contact Support/TAM

...rather than having a big red bar saying DENIED and possibly jeopardizing the customers experience with Red Hat?

I am also raising this because I have had this conversation with multiple customers and some of my Partner accounts as a TAM over the years.  I am seeing the conversation more and more these days.

Public examples:
https://www.redhat.com/archives/rhelv6-list/2012-January/msg00031.html
https://www.redhat.com/archives/rhelv6-list/2012-January/msg00036.html

Comment 1 Simon Green 2012-01-30 21:48:47 UTC

(In reply to comment #0)
> Could we make a response that can educate the customer as to why the
> possibilities the bug is marked private?  

Yes.

> Could we drive them to go to the
> Customer Portal and contact support or their TAM for more information?

We already do. On the Bugzilla homepage, "Red Hat Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system." and "If you are a Red Hat customer with an active subscription, please visit the Red Hat Customer Portal for assistance with your issue." (with a link to the portal)

>  Could
> we at _least_ provide the Technical Notes in a public fashion?

No, there are many reasons why a bug could be marked private. I know for the Bugzilla product, I wouldn't like any information from that bug to be shown. Additionally, a Red Hat partner would expect all the information they submit in a bug to be private.

> Could we get private bugs that are resolved to show...:
...
> Could we get private bugs that are not resolved to show...:
> 
> ...rather than having a big red bar saying DENIED and possibly jeopardizing the
> customers experience with Red Hat?

No. Red Hat Bugzilla is a bug tracking system, not a customer support platform. This is mentioned on the Bugzilla front page.
 
  -- simon

Comment 2 Simon Green 2012-05-01 03:39:32 UTC

*** Bug 237550 has been marked as a duplicate of this bug. ***

Comment 3 Petr Spacek 2013-01-24 15:37:39 UTC

(In reply to comment #1)
> (In reply to comment #0)
> > Could we get private bugs that are resolved to show...:
> ...
> > Could we get private bugs that are not resolved to show...:
> > 
> > ...rather than having a big red bar saying DENIED and possibly jeopardizing the
> > customers experience with Red Hat?
> 
> No. Red Hat Bugzilla is a bug tracking system, not a customer support
> platform. This is mentioned on the Bugzilla front page.

Agree with both of you :-)

Red Hat Bugzilla is a bug tracking system, not a customer support platform - for sure.

On the second hand, more polite and explanatory error message costs almost nothing and could improve public image a lot. (The impression is also very important! Did you look to mailing list archives - Robin provided links in bug description.)

As Robin proposed:
3)  Possible reasons why the BZ is private (Legal fluff here)
4)  For more, go to Customer Portal and contact Support/TAM

Both points above are simple string change, aren't?
Point 3: "This bug is not public because it contains customer data. Red Hat is committed to protect all customer data." or anything else Legal provides.

Point 4: Link to Customer portal with two explanatory sentences.


Robin's first point is also very very good idea, but why don't start with simpler string changes :-)