Something that annoys me the most:

[Dieselboy]

Reading some release notes looking for caveats that are resolved and open ones that might effect us to determine if we can use that software or not. I see an ambiguous bug description (not uncommon) so I click on it for more info and I'm taken to a page which shows the attached screenshot.

Why?

Not why, as in why is the error displayed. WHY! as in why does the release notes contain a bug ID which is private to Cisco only? Make another bug ID, link them and cut down the secret information so that the customers can read the release notes properly!

Sort it out, Cisco. Most of the time when I report these (when tac give me bug ID's) they simply go and flick the switch to allow it to be viewed by customers, anyway.

[deanwebb]

When I worked at MSFT, we had internal KB articles, but that was because they hadn't been verified and edited. We could read them and mention a few things from them to customers on the phone, but they weren't available or mentioned publicly. And if we had a public caution about a feature, we had a public KB ready to go with it. It's good support practice to make sure that your documentation can keep up with your fixes.

It's possible that the "proprietary information" is just bad grammar and the editor needs to get to it.

[Otanx]

At least Cisco gives you a bug ID that you can reference when calling TAC. I am working with another vendor that does not list the bug ID in release notes. So I get to have fun conversations with their support while they try to figure out the details of the vague "Feature X does not work sometimes" line in the release notes. Pretty much the only reason we have this product is because of feature X, and they can't tell me under what conditions it isn't going to work because all the tier one guy can find on that bug is that line in the release notes. Currently waiting on tier two to get back with me.

-Otanx

[Dieselboy]

Wow that's terrible Otanx! Way worse than my OP.

Good insight Dean