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 2 Part 3

Over the course of the next few days, hundreds of Drupal enthusiasts will be hopping on planes and heading to London to attend DrupalCon 2011. Unfortunately, I will not ... which means I won't be there for webchick and hejrocker's 'Project Application Process Revisited' core conversation.

As mentioned in this blog's first post, my experience with Drupal's "Project Application Process" is the catalyst which spurred my increased involvement within the Drupal community. As a new Drupal contributor, I found the process painful and extremely de-motivating.

Despite the best efforts of a small group of volunteers, the application backlog has grown to the point where applications may sit for weeks before an initial review, and some may go months from initial ticket to resolution. In the interest of improving this experience for future contributors, I joined the Code Review group on g.d.o ... and as the group members can tell you, I have plenty of thoughts to share on the topic.

Since I won't be at DrupalCon for the core conversation, I'll be posting some of those thoughts here ... and hopefully others can represent my comments in London.

Why an Application Process?

Mission Statement:The Full Project Applications review process will ensure that new contributors have a basic understanding of the Drupal Community’s core values concerning contributing code to Drupal.org, as well as to promote lasting, long-term contributions to the project.

The basic goals of the Project Application process can be summarized as follows:

• Ensuring that modules abide by Drupal legal and security requirements,
• Encouraging collaboration with existing modules, reducing module duplication where possible,
• Encouraging the following of established coding standards,
• Mentoring and support of new contrib authors, encouraging the use of drupal best practices and approaches, and
• Encouraging and fostering further contributions and involvement in the community.

Personally, I see great value in having some sort of application or screening process ... especially when you consider the legal and security implications associated with the hosting of code on Drupal.org. Such a process helps to ensure a consistent quality standard for contributed Drupal modules, and imposing a slight barrier of entry helps ensure that a contributor is serious about their project.

Today's Process

Before a new contributor can post their first module to Drupal.org, they must first apply for permission to create 'full' projects. The basic process is:

1. Create a sandbox for your project
2. Post some code to the git repository
3. Open a ticket in the 'New Project Applications' queue
4. Wait for someone to review the code and mark it RTBC
5. Once the issue is marked RTBC, a git administrator grants the 'Full Projects' permission

Looks simple enough, right? Unfortunately, things start to break down at #4. I'll touch on a couple of the root causes below ... For a more detailed analysis, feel free to check out my related post in the Code Review group on g.d.o.

Issue Number 1: The 'Front Door' Bottleneck
Contributors may have any number of reasons for submitting a module through the Project Application process. Whether its a desire to leverage Drupal.org as the distribution channel for their module, a contractual obligation related to the sponsorship of the module's development, a sense of accomplishment or personal pride seeing their work 'published', or the sheer joy of giving back to the community ... we greet all new contributors equally:

Hello, you have reached the Project Application review helpline. Your contribution is important to us. Please hold until our next available reviewer is able to take your call.
...
You are currently the 254th caller in the queue. Your estimated wait time is 34 days. Thank you in advance for your patience.

For many potential contributors, the project application process is their first non-support interaction with the greater Drupal community ... a community which prides itself on openness, cooperation and collaboration. Unfortunately, the impression we give first time applicants is anything but open and cooperative. Instead, we ask them to take a seat and wait in line, and hope that the good ones might have enough patience to wait around long enough to see the process through. In today's age of 'instant gratification', this simply isn't good enough.

Issue Number 2: Application Queue backlog
Why does this front door bottleneck occur?

Well, here are some basic metrics regarding the application queue:

Queue Size
Currently, there are 423 active apps in the queue.202 of these are sitting in 'needs review' status.
Application Age
Oldest CNW application: 57 weeksOldest 'needs review' application: 49 weeksOldest application with 0 comments: 9 weeks
Apps In vs. Apps Out
In the last week:21 New Application9 RTBC/Fixed Applications
#of active reviewers
Varies, but estimated between 5 and 10 for any given week.

 
Clearly, this backlog of applications is unmanageable, given the low number of volunteers actually performing reviews. It is this sheer volume of applications which results in applications sometimes waiting more than 4 weeks for an initial review, or even longer for a follow-up.

Issue Number 3: 'Project' Approval versus 'Developer' Approval

While the full project application process is just one process, successful completion of this process means two things:

• The module is vetted as ‘ready for inclusion’ in the official contrib project lists, and can thus be promoted to an ‘official’ project with an ‘official’ namespace … in other words, it becomes a ‘real’ project.
• The applicant is vetted as ‘ready to be trusted with the “promote projects” ability’, and is thus let loose to create whatever future official contrib modules projects they want, no longer subject to any sort of limitation or review.

With the existing process, these two items are interdependent. If you approve the module, you approve the reviewer. If you deny the module, you deny the reviewer. Personally, I believe that separation of the ‘project approval’ process from the ‘developer approval’ process is needed.

As an illustration why, consider the following scenario:

Occasionally, an applicant spends a couple months in the project application process, waiting weeks for reviews and addressing each issue found … only to have a new reviewer come along at the end and point out ‘this module is a duplicate of module X’. Even if the contributor has successfully demonstrated their competence with regards to best practices and knowledge of the Drupal APIs, as well as the dedication to stick with it through the entire project application process … a ‘module duplication’ claim essentially blocks the entire application.

For that user to be granted the ‘promote projects’ ability, they must go back, develop a new module, and start over at square one with a new project application (and all of the associated waiting which goes along with it).

In reality, the contributor's only real fault was not performing a thorough enough search before coding their project. And they end up paying a harsh penalty for that oversight ... assuming they bother to come back with a new project at all.

So what do we do about it?

Well, for starters, if you're at DrupalCon London, consider participating in the 'Project Application Process Revisited' core conversation being hosted by webchick and hejrocker.

As far as potential improvements to today's process go, I'll identify a few options in my next post.