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 21:00	Modified:	1 Nov 18:04
Reporter:	Peter Laursen (Basic Quality Contributor)
Status:	Verified
Category:	bugs.mysql.com	Severity:	S3 (Non-critical)
Version:	n/a	OS:	Other
Assigned to:		Target Version:
Tags:	qc
Triage:	Needs Triage: D3 (Medium)

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