There's a whole chain of inefficiency spawned by each poorly qualified bug:
1) QA reports a bug with a title not matching the actual issue close enough
2) The bug slips through spot-checks with incorrect priority assigned due to inconclusive title
3) Developers spend time to fix lower priority bug or miss fixing higher priority bug
4) Support team cannot fix/define release note correctly and spends much time including getting help from QA
5) Marketing team spends time copy-editing poor release note grammar or semantics
6) Finally customers get lower quality release or delayed release with incomprehensive release notes
Solution - QA
Peer-reviews: if devs can peer-review code, QA can also peer-review new bugs
a) Make pairs, i.e. team member 1-2 and team member 3-4
b) Define review schedule - each day, just before sending test summary (this is up to you)
c) Suggest corrections to your team pair about all bugs that don't look correct
Once we get the final summary, both the bug owner and the bug reviewer will be held responsible for poor bug title, incorrect priority, stds issues, etc.
Apply the same to new test cases
Solution - Support
As prime owners of release notes you shouldn't bow your head down and keep nagging while rewriting poor release notes
a) For each release note you need to open a corresponding bug in order to rewrite it, write down the bug owner name
b) Compile a simple rank list (leaderboard) 1, 2, 3, 4 - from most to least frequent bug owner who you needed to correct
c) Include the leaderboard along with each corrected and approved release notes
