Presenters: Angie Byron, Greg Dunlap Problem: In order to create full-fledged modules, new contributors must go through a strenuous peer review process that involves checking for security problems, misuse of Drupal's APIs, coding standards, and duplication. Last year at DrupalCon Copenhagen, a session was given that explained why we had a project approval process, and talked about the damage this process does to the community, to attempt to come up with a plan to help ease some of the suffering. A year later, we now have Git, and we have sandboxes available to all authenticated users. Have things improved for the better, or gotten worse? How has the process changed? Proposed solution: Data. We mine the Drupal.org database and report our findings. What's the average wait time of people in the approval queue? Is the review team actually finding and stopping security holes before they get introduced? What's our attrition rate like, after someone goes through the application process? Is webchick just overreacting? From here, we discuss next steps. We'll propose some of our own, but are really interested in a discussion from the folks in the room about what can be done to balance the legitimate needs of the security team and our community, without bludgeoning new contributors in the face.

1. The Project Application
Process, Revisited
Greg Dunlap
Alan Palazzo
Angela Byron
Thursday, September 1, 2011

2. The process
1. Create a sandbox
2. Commit your code
3. Create an issue in the “Project applications”
queue
4. Wait for someone to review/RTBC it
5. Profit!
Thursday, September 1, 2011

3. The problem
1. Create a sandbox
2. Commit your code
3. Create an issue in the “Project applications”
queue
4. Wait for someone to review/RTBC it
5. Profit!
Thursday, September 1, 2011

4. Step 4 tends to turn this...
I love Drupal!! I can’t wait to give back!
Thursday, September 1, 2011

5. ...into this. :(
Screw you guys. I’m going to Github.
Thursday, September 1, 2011

6. Why do we do this to
people?
• Impart community knowledge (coding
standards, best practices, etc.)
• Prevent proliferation of insecure modules
• Prevent module duplication
• Reduce insecure/broken code
• Ensure license/policy compliance
Thursday, September 1, 2011

7. So, is it effective?
Here’s what the data shows.
Thursday, September 1, 2011

8. What data we gathered
• Spot-checked ~60 applications (mix of
approved/declined), checked for:
• Reasons applications were sent back
• What happened after approval/denial
• Number of days people were in process
http://lb.cm/project-application-stats-spreadsheet
Thursday, September 1, 2011

9. Reasons for
“needs work”
Rank Reason Percentage
1 Coding standards 64%
2 API usage 45%
3 Application rules 33%
4 Duplication 19%
5 Legal or external libs policy 12%
6 Security 5%
Thursday, September 1, 2011

10. Conclusions
• New developers don’t know coding
standards, nor have in-depth knowledge of
Drupal APIs yet.
• Duh; neither did you when you were new.
• Our application rules and licensing policies
are confusing.
• It’s hard to find modules on drupal.org.
• (generally) Only security team members
find security holes in new modules.
Thursday, September 1, 2011

11. Process sustainability
http://jthorson.doesdrupal.com/project-apps-pt1
Average length in queue: 88 days
Thursday, September 1, 2011

12. Conclusions
• Process is unsustainable: too many eager
users, not enough people helping
• However, we do get a number of benefits:
• Easy way to impart Drupal community
norms on new people
• Easy way to catch legal issues before they
happen
Thursday, September 1, 2011

13. So what do we do
now?
Thursday, September 1, 2011

14. #1: Figure out our
priorities
What behaviour do we want to promote, what
behaviour do we not want to promote?
Thursday, September 1, 2011

15. #2: Focus on
automation
Keep humans on things humans do well; let machines
handle coding standards/security/legal review.
Thursday, September 1, 2011

16. #3: Separate mentorship
from access
Create a view of new peoples’ commits. Have code
review team focus on helping those people.
Thursday, September 1, 2011

17. #4: Create better
metrics/search tools on
drupal.org
Don’t take the lack of these tools out on eager new
people.
Thursday, September 1, 2011

18. Concrete proposal
• Get jthorson’s automated Coder review code deployed on d.o
• Expand with Legal / API sanity / security checking
• Display Coder status on project page to indicate project quality to
maintainers on full projects and all users on sandboxes
• Feed data into Solr to make search not suck
• Add “app review” bingo
• Add steps for what new reviewers can do
• Add git clone command to project issue
Thursday, September 1, 2011

19. Other ideas
• Move reviews to first stable release, rather
than first submission
• Enable dev releases on sandboxes
• Grant full project upgrade only to projects
with stable releases
• Time-box ability to get a namespace (e.g. 2
months since first push)
Thursday, September 1, 2011

20. But seriously, let’s figure
this out this time.
Thursday, September 1, 2011

21. The real proposal
• Automated coder
review on project page
• Sec. / legal to follow
• Allow dev tarballs on
sandboxes
• Move approval process
to stable release, limit
project namespace to
stable release
Thursday, September 1, 2011