Chris has a point. There's definitely an implicit "rejection policy" already in place.
Given a strong rejection policy, there are 2 opposite spectrums to its implementation. You can follow the Singapore method that says "Our fatherland says this, so this is it. You cannot make a U-turn because the law book didn't say you can do so on that road". Or you can say "please try to do this, but we'll look at your case and let you through the first few times". (Frankly, the 1st method is LAZY; the 2nd takes more effort and is human-friendly.)
I've submitted about 3-4 patches, 3 (75-90%) of those early patches have wrong "path to file" (I created patch from same folder as patched file, not from root with folders like application, framework, etc). Jacopo mentioned it to me twice or thrice. I got the message.
But of course, there can be those who are completely out of line all the time, no matter what you tell them.
Still, it could definitely save Jacopo A TON of time if he were officially allowed to respond with short default message: "Sorry, I can't look at your patch at all due to time constraints. Please refer to best practices page to correct your patch first. Or give patch to some kind community member who will correct it for you. Sorry for the inconvenience."
Now that would be better than: "Sorry, patch no good. Please try again." I don't see anyone ever doing this, though.
Jonathon Chris Howe wrote:
Being tempted to ask for a vote, insinuates that you want to condone a practice whereby if you go to review a patch like in Adrian's case and it has superflous formatting changes, that you would delete it from JIRA in a "sorry kid, you're wasting my time" dismissal (email impressions added for levity). Anything less is what is currently going on and wouldn't need a vote. People aren't tempted to vote on the status quo.
