Revisiting Drupal's "New Project Application" Process (Part 2)
This is the second post in series regarding Drupal's New Project Application process. The other posts in this series can be found here: Part 1 Part 3
Well, it's been a few weeks since my last post on this topic, where I had promised a follow-up with some potential options for improvement to the Drupal Project Application process. In the meantime, the Project Applications process was the subject of some debate during a core conversation dedicated to the topic at DrupalCon London ... ironically scheduled immediately after Randy's session on Burnout. (Check the links for the session slides/recordings.)
There have been a number of discussions on the topic since DrupalCon, all indicating a strong desire to fix this process. While the proposals range from minor tweaks to scrapping the whole works, I believe we are starting to come to a consensus regarding next steps in the evolution of the Project Applications process ... one which strikes a fair balance between the needs of the community and those of the applicants; and which helps eliminate the bottlenecks in today's implementation.
Currently, successfull completion of the application process grants applicants the ability to promote their modules to 'full project' status, which in turn allows for:
- Claiming an 'Official' project namespace
- Publishing 'official' project releases
- Publishing release tarballs on the project page
More importantly, In addition to the 'promote full project' abilities, successful completion means that the applicant gets full reign on the creation of future projects, no longer subject to any level of review, scrutiny, or approval. There are soft benefits as well, such as the sense of legitimacy associated with an officially namespaced drupal.org module (relative to a project sandbox) ... which can be an important factor when working with clients or project sponsors.
From the community perspective, today's project application process provides some key benefits which should not be overlooked or forgotten as we move forward. While the process is often cited as a huge barrier of entry for potential contributors, this same barrier also applies to folks with less honorable intentions ... while everyone agrees that we need to change things, we must be careful that we don't open the floodgates to a host of spammers, namespace squatters, and folks posting insecure or malicious code into the contrib repositories.
So some items we'd like to accomplish during any process changes include:
- Reduce barriers to entry for new contrib authors
- Continue to enforce Drupal security/licensing requirements
- Efficiently deal with the current backlog of project applications
- Avoid 'moving the bottleneck' ... ensure that our changes don't cause a sudden load increase for the security team
- Discourage namespace squatting
- (Under debate) Seperate approval of 'contributors' from approval of their 'modules'
- Restrict access to sandbox code for un-educated users (Since unrestricted sandboxes may contain just about anything, downloads should be slightly more difficult to obtain than for a full project release.)
In the meantime, our evolution of this process can also provide benefit to other sandbox projects (automated testing for core initiative sandboxes, as an example). However, throughout this evolution process, we also need to practice diligent restraint ... ensuring that, in our haste to change, we do not over-correct. Removing barriers is easy ... but replacing them once they've been taken away is a completely different story.
While I won't claim community consensus on the full picture, I believe that you'll find general agreement on the roadmap forward ... specifically, automating as much of the review process as possible, in order to provide instant feedback to potential contributors and eliminate the front-door bottleneck. In the short term, this means automated coder reviews ... in the longer term, it means adding automated XSS and other security screening to the testing infrastructure as well. With both of these in place, I believe there is some appetite for removing the human review process as a requirement for a new contrib author wanting to release a new project.
I have been working on the Automated Coder piece for some time, but as I've discussed in a previous post, the testing infrastructure keys off of actual release nodes for much of it's operation ... and sandbox projects can not post actual releases. I think the optimal solution here would be to reverse some of the changes introduced with #994260: Add a setting to disable releases for sandbox projects (though it's possible that toggling the setting may be sufficient), and add a new setting which disables the 'download' block for sandbox projects. This would allow coder automation work to move forward, while addressing potential concerns around making it too easy for un-educated users to get their hands on sandbox code. For anyone interested in helping move this forward, I think enabling the above would be a great low effort/high reward way to get involved!
The other missing piece in the short term is the ability to view a project's test results on the drupal.org project page for that project. I've taken a preliminary stab at this in a project sandbox located at http://drupal.org/sandbox/jthorson/1238958 ... but would be happy to defer to another's attempt on this task.
Of course, these steps only address the enabling of automated reviews to replace today's human reviews ... there are still a number of items to hash out with the rest of the process. I'll close off this series by outlining my version of what the potential end-to-end process could look like in my next post.