MySQL Bugs: #48455: Request for guidelines on when bugs may be marked as private

Bug #48455	Request for guidelines on when bugs may be marked as private
Submitted:	31 Oct 2009 20:00	Modified:	1 Nov 2009 17:04
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Websites: bugs.mysql.com	Severity:	S3 (Non-critical)
Version:	n/a	OS:	Other
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
I see an increasing trend to mark bug reports as private here. 

Latest example I encountered is:
http://bugs.mysql.com/bug.php?id=48131

an example a few months old:
http://bugs.mysql.com/bug.php?id=46384

How to repeat:
Don't repeat, please.. unless the purpose of 'privatization' is to protect users against security vulnerabilities as long as a patch does not exist.

If the purpose of 'privatization' is to protect the business or	reputation of MySQL/Sun or the reputation of individuals in MySQL/Sun organization is is a very bad practice - at least for Open Source software. 

Over the last around 6 months I have seen quite some becoming 'privatized'.  All those I know from before there were 'privatized' all relate to server crashes. A crash in itself is not sufficient reason, I believe. A crash is not a security vulnerability.

Suggested fix:
Document guidelines for when such 'privatization' may happen, make the guidelines public and respect them.

.. additionally do not forget to 'un-privatize' reports once a problem is solved. It is very important for every vendor in the MySQL ecosystem to be able to search&find information about all issues. Only then we can 'workaround' issues and advise our users and customers how to handle those (upgrade or not upgrade, rewrite queries, manage indexes or whatever).

There are guidelines, and there are people who decide should bug report be private or not. In general, when the bug is Closed and versions with the fix are all released, bug report should be made public again (with some comments still private if necessary). One of your examples shows that this did not happen. We'll try to find out why and is any automation possible.

As for publishing guidelines and all the reasons for bug-related decisions, I am not sure we can and should do it. Even if we do, there are people with power high enough to set bug to private just because they think it is reasonable. You can't change this. But Closed bug in already released software must be public, for sure.

It is not so much automaton I request (it may help following up though) - but rather 

1) that the criteria for privatization should be described for the public.
2) and in case a non-MySQL person reports a bug that gets marked as private is this privatization then discussed with or at least communicated to this person with a proper explanation why.

If such transparency does not exist people may prefer to publish their findings elsewhere than here in this bugs system (like blogging about it for instance) once they have experienced their bug reports become privatized. I think you have privatize too many bugs recently - but I do no have exact statistics of course.  It may be just because I have subscribed to more bug reports for the last 5-6 months than what I did before.

Actually the background was that I was looking for a test case in a bug report from earlier this week. I wanted to try some variations of it. I cannot find it now - and I think it may be inside the first bug report I linked to.

Per #2 above - a person can always see the bugs they reported (if they are logged in) - even if the bugs are marked private