Code review for security advisory coverage applications

As klausis pareview script is very helpful to detect typicall project application problems I tried to set up an online service to make it easier for applicants to use without setting up a testing environment.

It was a all-in-one-day project, written quick and dirty - but It's working and maybe it'll also be useful ;-)

It can be found here: http://ventral.org/pareview

Klausi's post in the Community Spotlight.

I think the project application process is hugely important to our community and even though there are efforts under way to automate much of it, it's clear that we will still need some human involvement for a good amount of time to come. I see community spotlight posts as a great way to help thank the folks who are doing this work and to help draw attention to the need for more helpers.

I feel like there are people who feel comfortable doing the regular review, but not the security review portion of a typical review. So, I'd like to share with some folks how I tend to do that in one-on-one sessions. I hope that by doing these one-on-one it will provide more confidence to those folks than a blog post or screencasts or whatever might do.

We spend most of our discussion here talking about what isn't working, so I thought it would be nice to point out something awesome: we are currently down to only 100 issues in the "needs review" queue. That's a number we can get through in the next week, and then have no backlog for the very first time ever since sandbox reviews started. Reviews should be much, much smoother after that. Yay!

With the backlog being what it is, is it a good idea to reply to any new contributions? Even if you haven't reviewed their code yet. I've noticed from the few pieces I've looked at that there are a lot of basic errors that really slow down the whole process. So a standard reply asking for patience, if the opening post isn't strictly as procedure is a tiny bit about how it won't stop your application from being handled but will slow the whole thing down yada yada.

Something like this:

I know what it feels like to have your hard work critiqued, piles of issues to solve and to deal with some of the hardest discussions and posts we can have. I know the many hours spent, sacrificing time with our loved ones, time without sleep or the so many other things we give up to do our part.

Interesting debate going on in http://drupal.org/node/1162758 ...

The applicant has submitted a module which requires a core edit ... the core edit basically adds a new hook to core, which the module then takes advantage to implement its functionality.

In discussion, the applicant makes the following point:

So, why don't allow people to make a choice themselves? Publish the module and we will see whether it is convenient to add 1 line of code to the core or not.
There are some modules out there that required lot more of core modifications.