A great QA team essentially does the following:

Documents what makes good QA. This is obviously the most controversial part. We have seen QA leads in the past essentially make arbitrary demands of developers for what is viewed by many as little or no gain. Some policies will not be followed. That is OK (see below).

Prevention: The QA team should encourage the authoring of tools to prevent errors making it into the tree. Repoman and echangelog are two such tools. There could (and likely should) be other tools. Tool should encourage doing the recommended thing.

Detect when problems occur, via developer tools and automation. The current team does this for many violations, however there are obviously a class of violations that are not automatically detected.

I would like to see policies have some sort of severity. For instance violating a policy might have very bad effects (broken user machines) or just bad effects (breaks dep-tree) or minor effects (missing Changelog entries).

I could see developers getting suspended for committing a severe violation. I cannot agree as much with suspending or firing developers for minor violations. In many cases the policies are in fact recommendations on how to write ebuilds, code, metadata, etc. and have edge cases that are not well specified or covered.