The Project Application                   Process, Revisited                              Greg Dunlap                     ...
The process                    1. Create a sandbox                    2. Commit your code                    3. Create an ...
The problem                    1. Create a sandbox                    2. Commit your code                    3. Create an ...
Step 4 tends to turn this...                              I love Drupal!! I can’t wait to give back!Thursday, September 1,...
...into this. :(                              Screw you guys. I’m going to Github.Thursday, September 1, 2011
Why do we do this to                          people?                    • Impart community knowledge (coding             ...
So, is it effective?                                Here’s what the data shows.Thursday, September 1, 2011
What data we gathered                    • Spot-checked ~60 applications (mix of                              approved/dec...
Reasons for                               “needs work”                Rank                   Reason                 Percen...
Conclusions                    • New developers don’t know coding                              standards, nor have in-dept...
Process sustainability                                  http://jthorson.doesdrupal.com/project-apps-pt1                   ...
Conclusions                    • Process is unsustainable: too many eager                              users, not enough p...
So what do we do                                   now?Thursday, September 1, 2011
#1: Figure out our                                     priorities                              What behaviour do we want t...
#2: Focus on                               automation                    Keep humans on things humans do well; let machine...
#3: Separate mentorship                        from access                      Create a view of new peoples’ commits. Hav...
#4: Create better                 metrics/search tools on                       drupal.org                     Don’t take ...
Concrete proposal                    •         Get jthorson’s automated Coder review code deployed on d.o                 ...
Other ideas                    • Move reviews to first stable release, rather                              than first submis...
But seriously, let’s figure                   this out this time.Thursday, September 1, 2011
The real proposal                    •         Automated coder                              review on project page        ...
Upcoming SlideShare
Loading in …5
×

Drupalcon London 2011: Project Application Process Revisited

1,063 views

Published on

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.

Published in: Technology, News & Politics
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
1,063
On SlideShare
0
From Embeds
0
Number of Embeds
136
Actions
Shares
0
Downloads
3
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Drupalcon London 2011: Project Application Process Revisited

  1. 1. The Project Application Process, Revisited Greg Dunlap Alan Palazzo Angela ByronThursday, September 1, 2011
  2. 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. 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. 4. Step 4 tends to turn this... I love Drupal!! I can’t wait to give back!Thursday, September 1, 2011
  5. 5. ...into this. :( Screw you guys. I’m going to Github.Thursday, September 1, 2011
  6. 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 complianceThursday, September 1, 2011
  7. 7. So, is it effective? Here’s what the data shows.Thursday, September 1, 2011
  8. 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. 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. 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. 11. Process sustainability http://jthorson.doesdrupal.com/project-apps-pt1 Average length in queue: 88 daysThursday, September 1, 2011
  12. 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 happenThursday, September 1, 2011
  13. 13. So what do we do now?Thursday, September 1, 2011
  14. 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. 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. 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. 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. 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 issueThursday, September 1, 2011
  19. 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. 20. But seriously, let’s figure this out this time.Thursday, September 1, 2011
  21. 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 releaseThursday, September 1, 2011

×