Applicants' motivation analysis and possible conclusions

I added this as a comment to a different thread but no one seems to have found it there (hopefully not to have not liked it ;)). I dare moving it into a standalone discussion as I would really like more opinions on it. Hope you don't mind.

Since my own (after all, praise!, successful) application is really not long ago, I personally see three main thoughts leading applicants to the queue. I would like to first explain them and then make some suggestions on possible consequences.

1. To be within the results of a module(, theme,...) search not just if someone actively extends the scope to "sandbox". A term that may cause associatons to "kindergarden" or whatever at least to site builders who are quite new to Drupal. (Pardon me, but please finish reading first.) And who would really want to promote the results of, probably, endless coding nights with a "sandbox" label. I think this is the most common motivation.
2. To participate from the packaging script advantages. I think that only few are aware that even sandbox projects may be easily obtained as a tarball behind a path like user/sandbox/123456.git/snapshot/refs/head/branchname.tar.gz. This is, IMO, the second most motivation.
3. To make sure one's premiere is pretty perfect, has no vulnerabilities, respects all Drupal API standards, is easy to read for anyone who aims to extend it and so on. Some applicants are really interested in this, be it because they have already bothered patching others' people projects or core, be it that they have certain quality demands against themselves. But I think, there are also many who do not (primarily) care about that. For whatever reason.
4. To learn, improve, have someone mentor you and reveal things you have missed. In other words, to show you at how many points you have "deficites" and need to improve. Come on, folks. No one wants this, at least unless understanding that there is nothing bad about that and, oppositely, he will nothing but benefit from such a process. But most definite this is a learning curve we all went (or still have to go) through, isn't it? ;)

So what would be simple a way to satisfy these needs and, ideally at the same time, have the review queue drastically reduced without giving up on the demands we all share regarding good and approved code?

I will just throw in my conclusions for each item, maybe some of you might agree.

1. No more "stigmatizing" for unapproved projects. That sounds a bit tough, but it actually is what we do. Let us change the project search form as follows:
   • No more "select" ("full projects", "sandbox"), which, besides, anyway is not conform with Drupal interface standards (selects only for choices with at least 5 items).
   • Instead of that a checkbock (unchecked by default but probably optically emphasized) "only fully approved contributors".

   Checking this box, you will have results as currently when selecting "full projects", otherwise any. Why this? I think it is a psychological improvement for all who just want to add, but not get too deep into our community. Why bother forcing them into a review process the benefit of which they wouldn't really anticipate at all? Just think of all those "I have a commercial payment service and want it to be available in Drupal with a kind-of-a-bridge module" applications. They cause annoyance for the applicants and much work for reviewers. I see already many comments pointing to e.g. wordpress' policy, fivestar ratings etc. Right way, subscribed. But let's do it even better and create a "approved contributor" badge that pushes their projects to the top of any result. And damn, make it hard to earn, yeah. Also, link the badge towards an explanation page so everyone who wants to know may read why this very project is a quality choice.

2. Let anyone have an "add release" option and revise the color schemes. "Quality projects" will have a green label for release packages (as currently) but a yellow(/blue) one for dev snapshots (instead of the red one). Sandbox projects will then have no more but the red one plus, eventually, a warning ("unapproved contributor, installation AYOR" or similar). This would satisfy both our demands towards qualified code and the desire of many contributors just to throw back *something*.

For those applicants who understand the benefit of 3) and probably even 4) and/or who aim to having the "quality" badge: Keep the review process as tough as it is. Probably even tougher. Find the latest ridiculous trailing whitespace, harass them with indention and whatsoever (not for the harassment itself of course, but just to show "we're serious with it"). Let us do all this nit-picking with cool scripts as klausi and others have developed. Implement jthorson's initial proposal in some way. Automatize as much as possible and do really in-depth manual security, API and whatever reviews. While the process may become longer on one hand, no one will feel as pressurized as currently, thanks to proposal 1) and 2). And hopefully, the queue might become much smaller than ever before as some may decide to abstain from the "quality seal" and just be fine with their improved and renamed sandbox status.

Oh, and: If we are going to have user driven ratings (five- or whatever -star), they should of course be separate from our "quality seal". I.e. second "order by" clause in any query, not first. As many advantages as "democratic" ratings actually have, they are never a final warrantor for quality. IMO at least.

OK, hope you don't find my thoughts too strange. Looking forward to your objections.

-dave