Be the first to like this
Angie Byron, Greg Dunlap
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?
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.