PHP_CodeSniffer as part of the pepr proposal process

I just spied this in another thread, and thought, "of course", how obvious.

Waiting to comment until the voting phase isn't how the system is supposed to work. I think there is a big gap between how the system is supposed to work and how it works: 1) People put packages up for public criticism then act all offended when they receive said criticism. 2) Lots of developers only complain about docblocks / licenses / CS. A bot can be written that will do exactly the same! People are either unwilling to look into the actual workings of the package or unwilling to "offend" their fellow developers. Thus me keeping my comments for "easily offended" developers until the voting phase won't make this gap *much* wider, I suppose...

How difficult would it be to provide: 1. really clear directions on installing and running PHP_CodeSniffer over your proprosal 2. (and most desirable) the ability for a proposal (phps; or archive) to be evaluated automatically with PHP_CodeSniffer against PEAR standards before allowing a package to go from proposed to call for votes (or whatever stage you want to put it at)? -- By a factor of three, what you do is not nearly as important as how it makes people feel; so why do you spend almost all your time on the wrong thing?