Purpose of the Project Application queue

The queue's purpose is not sufficiently stated, and the complaints I've seen arise from that.

The first purpose is to evaluate the applicant in order to grant "git vetted user" status.

We do this mainly by evaluating a submitted module's code. Too often applicants and even sometimes reviewers confuse the module-review portion with the main purpose of the queue. A more perfect module is not actually our goal.

A third portion of the process is code mentoring. This closely overlaps with the review process' checkbox for "Proper use of the Drupal API." And as one of the fuzziest requirements, this is where we get into trouble - too strict, inconsistency among reviewers, &c. However this is also one of the most important pieces - it's our 1 and only chance to influence new maintainers before they are let loose in the world of contrib.

So what's our goal again? To grant an applicant the power to publish an unlimited number of modules in any state they choose, not to publish one particular module.

I believe we can categorize most applications, and require applicants to choose a category in the initial post. This will focus the reviewers' actions and prevent complaints. Categories such as:

1. I want to publish this one module and am not interested in receiving "git vetted user" status.
2. I would like code mentoring, and to eventually be granted "git vetted user" status.
3. I would like to be granted "git vetted user" status as quickly as possible, and am not interested in code mentoring.

Number 1 is already allowed by our review process, but applicants may be unaware it is an option.
Number 2 is our typical review process, with full reviews from a variety of reviewers.
Number 3 is the only real change I'm proposing. Reviewers will be limited to blocking issues only. For applications in #3, the "Proper use of the Drupal API" check should be inverted to "No improper use of the Drupal API". What's improper? Not using t(), security holes, or code that belongs in a hook_function(). Probably more items as well - but the point is that they're well defined issues which we document and can then reference in the review.

To those who say we're too strict (contrib doesnt require xyz...) - I say "Yes!" It's our one chance to guide you. Work with us on this one module and then you're free! Try out our code standard at least once, our git implementation, our file structure, etc. These are regarded as best practices in Drupal - try it once, and if you don't like it, you're free to publish future modules however you like.

To those who say the process takes too long - go with Number 1 or 3!

To those who say, I don't care what these random people have to say about my code - go with Number 3!

Those who say the reviewers are inconsistent - yes, that's the nature of people. But you chose Number 2! Change your application to Number 1 or 3 if you don't feel the mentoring is helpful.