When I've got a bug that's affecting my customers and the quality of service I'm offering, I could care less if its been "sanitized" and internal engineering comments / cuss words / etc has been removed - I want the *info available*, or at least indication that the problem *is* an acknowledged bug and NetApp is working on it, as *soon as possible*.
Not to be an apologist for Netapp, but I have seen other reasons offered from time to time. For example, internal bug reports can contain portions of source code or other proprietary facts about the internal workings of the filer, bugs that are mischaracterized (which could mislead the unsuspecting customer into thinking it is something else), or even disagreements between engineers over the nature of the bug involved. I think these sorts of things should be filtered.
Bugs may also contain proprietary information about our customers, and how their environments work, so exporting them unfiltered is simply not an option.
That is not, of course, to say that we shouldn't try to get more of them up. My recollection is that when we first instituted bugs-on-line, we decided to put up new bugs moving forward, rather than exporting our entire existing database, simply because of the amount of work involved. (You've got to start somewhere!) Hopefully someone more closely involved can explain exactly what we did, and what plans, if any, we have moving forward.
Dave