Buried in the sand(box)

This has long been a concern, and one with enough associated baggage and pain that even some of our most proficient catalysts and cat-herders have stepped in to try and resolve the issue, only to throw up their hands and walk away out of sheer frustration. As Ian has noted above, the number one issue with the current process is that it is volunteer driven. However, applicants see the folks doing reviews more as 'traffic cops' or 'hurdles', rather than the 'mentor' role the process was designed for, which in turn breeds a competitive atmosphere instead of a collaborative one. This make the process much less rewarding for volunteers, and drives them to look for other areas of the community which could benefit from their contribution. Another concern is that many interpret this as a 'module' approval process, rather than a 'developer' approval process ... and criticisms of the process are thus focused around achieving 'code perfection' instead of 'contributor development'. Personally, I feel we need to somehow decouple these 'module approval' and 'developer approval' aspects of the process; separating the rights to publish a single module from the 'vetted git user' right (i.e. the right to unilaterally publish all future modules); and thus allow some sort of a fast-track route out of 'sandbox' status for those that aren't interested in the long-term 'create full projects' permission. Eventually, most criticisms of today's process come down to the fact that sandbox modules are treated as second-class citizens, much as you have observed. The lack of pre-packaged tarball releases was done intentionally, for a couple of reasons. First, is the protection of the 'user who doesn't know better', which most people comment on. The second reason is also one of the main reasons that we have a developer approval process in the first place ... and is sadly one of the most often overlooked consideration in this ongoing debate. Drupal is unlike any other open-source project that I am aware of, in that the Drupal Security Team also takes on a certain accountability for community-contributed code, in addition to the core project code base. The Security team will accept, coordinate, and generate Security Advisories for any contrib project with an official release ('official' not including -alpha, -beta, or -rc). The argument is that this is one of the distinguishing factors and a key differentiator for Drupal ... but this policy would not be sustainable if we simply opened the floodgates and allowed anyone off the street to create a Drupal.org account, upload code, and create a fully packaged project release. Over time, we have built an certain trust with the user base that modules listed on Drupal.org are (somewhat) trustworthy. We are victims to our own success, and maintaining this trust and reputation has come with certain compromises in other areas. Now I'm not saying that the status quo is the 'right' answer ... the current lack of volunteerism in the queue has solidly proven otherwise. But it is all we have for the moment, until folks offer up i) an alternative, and ii) the resources to implement it. To be frank, it was the pain that I experienced bringing a project through the process that motivated me to step up and try and automate portions of it (which in turn led me to an equally neglected area which needed attention, and I now find myself maintaining the automated testing infrastructure). The challenge I see is that changing this process is not a one-man job ... we need more people who are not simply content with pointing out the flaws, and who are willing to step up, put in some hard effort, come up with alternate solutions, and implement the change that everyone seems to be asking for. Ongoing criticisms without action only serve to demotivate those who are currently involved ... whereas seeing others sharing your passion and joining in to do something about it only encourages them to work harder.