We had just shy of a dozen people get together for a BoF meet at BADCamp last weekend. This post summarizes what was discussed, some new ideas which were identified, and what we see as some of the next steps in the Project Application Process evolution.

Recent Progress

First of all, the team shared an expression of appreciation for the amazing progress made in the Project Application Queue over the last few weeks. Thanks to the efforts of a number of reviewers, inspired in part by the superhuman output of Klausi (participating in 225 individual reviews in the last month), the 'needs review' queue was temporarily knocked down to nearly zero (from over 350 applications a few weeks earlier). While this is an amazing feat, and something to be celebrated, the team also agreed that this type of effort can not be sustained over the long term, and that automation of a number of standard review tasks is still required.

Automation

One of the advantages of automation is with regards to timeliness and how feedback is received by contributors. With automated review steps, feedback can be nearly instantaneous as opposed to having to wait for a volunteer reviewer; and automation takes much of the emotion out of an applicant's response to feedback - it's easier to accept a bot's judgement than that of another human.

A few items were discussed with regards to automation tasks. A number of the proposed automation checks could be handled through the introduction of new rules in the Coder module, including many of the desired security checks, file checks, and licensing validations. There is also the option of leveraging 3rd party tools for some of these tests, such as a lines-of-code analyzer which will also report on included license files (I miswrote the name of the tool, please add to the comments below if you know the site).

Mentorship

Mentorship is an important value within the Drupal community, but not currently an effective part of the project application process ... when mentorship is tied to access, it immediately sets the applicant on the defensive. Shifting the applicant/reviewer relationship away from this, and more towards a 'reviewers helping applicants beat the bot' partnership, should help reduce the natural defensiveness and help contribute to the mentorship aspect. Above all, everyone agrees that the project applications process needs to be a 'welcoming' process, not a roadblock one.

Security Quiz Proposal

There was also a fair amount of discussion regarding the proposed 'security quiz'. The major benefit of this approach is that it tests the 'person' rather than their 'code'. There has been some concern that such a quiz could easily be gamed; but the general response to this has been that even cheating on the quiz will provide an applicant more exposure to the typical security issues than today, where applicants fail to read the recommended documentation.

Auto-rtbc Proposal

Another large area of discussion centered around the Auto-RTBC component of the current Project Applications Revamp proposal. Most of the debate is with regards to the 'RTBC' component of the proposal; while there is generally no objection to a time-based 'shove' intended to help revive a stalled application. There may be alternatives to the 'RTBC' status, such as auto-bumping applications to 'critical', the introduction of a new 'needs attention' status, or otherwise flagging stale applications and bringing them to the attention of reviewers. It may also be possible to only apply an auto-RTBC policy to a subset of modules which are more likely to become stale, such as those which deal with obscure third party components or are extremely complex and difficult to test/review.

Dealing with 'Abandoned' Applications

We also discussed the process for dealing with applications which have been stuck in 'needs work' status for long periods of time. The recommendation coming out of this discussion is that applications which sit in 'needs work' status for 4 weeks with no new comments will have a comment added to the application, with friendly text stating "No movement on issue for x weeks. Issue will be closed in x days". Should the application continue to sit idle for this second window, then the 'bot' will move the application to "postponed (maintainer needs more info)" with some additonal friendly text.

Review Tools

A request was made for reviewers to share more details regarding some of the tools they use to simplify the review process, and post details regarding their process on the g.d.o group page; so that other reviewers can take advantage of those same tools.

Low Hanging Fruit

From a next steps perspective, the team identified a number of incremental changes which would help increase the efficiency of the review process. It is anticipated that these could be incorporated in a new drupalorg_projectapps modue for d.o. (A sandbox for this project has not yet been created ... feel free to take the initiative!)

• Implement the above recommendations regarding abandoned applications
• Create a hard link between the project sandbox and the project application (and vice versa).
• Add text to the project application 'new issue' form, outlining key 'before applying' and 'tips for success' points when creating a new application.
• Filter out 'fixed' in the 'issue status' dropdown on the edit issue form, so that the applicant can not set his own application to 'fixed' after addressing reviewer comments (resulting in the application slipping through the cracks)
• Investigate the new automation tools introduced by klausi and attiks, and incorporate the methods into a new drupalorg_projectapps module.

A huge thank-you to all who attended the BoF ... if I've missed anything, please let me know!