Presenters:Angie Byron, Greg DunlapProblem: 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.
Citation preview
1. The Project Application Process, Revisited Greg Dunlap Alan
Palazzo Angela ByronThursday, 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. Prot!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. Prot!Thursday, September 1, 2011
4. Step 4 tends to turn this... I love Drupal!! I cant wait to
give back!Thursday, September 1, 2011
5. ...into this. :( Screw you guys. Im 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 complianceThursday, September 1,
2011
7. So, is it effective? Heres 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-spreadsheetThursday,
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 dont 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. Its hard to nd modules on drupal.org. (generally) Only
security team members nd security holes in new modules.Thursday,
September 1, 2011
11. Process sustainability
http://jthorson.doesdrupal.com/project-apps-pt1 Average length in
queue: 88 daysThursday, September 1, 2011
12. Conclusions Process is unsustainable: too many eager users,
not enough people helping However, we do get a number of benets:
Easy way to impart Drupal community norms on new people Easy way to
catch legal issues before they happenThursday, 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 Dont
take the lack of these tools out on eager new people.Thursday,
September 1, 2011
18. Concrete proposal Get jthorsons 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. Other ideas Move reviews to rst stable release, rather than
rst 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 rst push)Thursday, September
1, 2011
20. But seriously, lets gure 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 releaseThursday, September 1, 2011