To release projects like modules, themes or distributions on drupal.org, contributors have to go through a time consuming process. This process is one of the main on-ramps for new Drupal contributors entering our community ... and we have neglected it for far too long. While we're working on solutions on how to make it easier for people to contribute code - while still assuring a certain level of quality - we must not forget the applicants already in the queue, waiting for their projects to be reviewed.
This is a draft! Something missing, not clear? Grammatical errors?
Reviewing project applications is easy!
Many people want to contribute to Drupal at sprints - but they think they can't, because a certain level of knowledge is necessary to be really productive while working with Drupal's core.
Reviewing project applications is the perfect alternative for new Drupal developers who already worked with Drupal's APIs but don't feel ready to hack core yet!
Get started and sign-up!
There is useful documentation and tools to help you!
Documentation
Tools
- Step-by-step checklist for reviewers
- Automated review of coding standard issues
- Text-brackets for common issues
Know what you evangelize
- Coding standards
- Code documentation and comments
- Writing secure code
- Project documentation
- Best practices
Note that it's also useful to have a look at the flipside of the process:
- Applying in the project application queue
- Common issues of applications and tips
- A checklist for applicants
Not convinced yet? Questions?
No problem! Please feel free to ask ...
- on IRC #drupal-codereview
- just comment below!
- directly and discretely by mail!
- and for sure @DrupalCon Portland!
We won't throw you into cold waters
We are happy about anyone willing to help and for sure we will instruct you to anything necessary!
So don't be afraid, sign up, you'll be in good hands ;-)
Our long-term goal would be to get some of the sprint participants "bitten by the review bug" and keep the momentum going after DrupalCon - but that's up to you!
Comments
I'd suggest a strong call to action ...
Perhaps something along the lines of 'We'd like to clear the queue ... If everyone at the sprint reviewed a single project application, we'd have enough reviews to clear the entire Project Applications queue ten times over!'
I don't think that for the
I don't think that for the people we're targeting (novice Drupal developers) it really matters how many applications there are in the queue. I guess it's rather about being an easier alternative to core-sprints, were they can quickly get started and feel useful.
Also.. setting "let's clear the queue" as target - I'd rather see some few good reviews than the queue cleared by people setting everything to 'needs work' just to reach the goal..
But yes, getting the queue cleared would be wonderful....
Good point (re: target
Good point (re: target audience). Of course, that puts me in a bit of a conflict of interest, since I'm also involved in the core mentoring sprints at every opportunity. :p
Awesome sprint!
I had a lot of fun! Thanks to klausi and patrickd for showing me the basics, and building some really nice tools on ventral.org. I reviewed a total of 69 projects (at the sprint and for about a week afterwards) and found most of them to be RTBC.
The modules seemed to be in decent shape after 4-8 weeks - people had already given tips on how to organize the repo and files and the basic cleanup was already done. I also think this is a reasonable amount of time for new developers to wait for a full project.
So I'm not sure actually clearing the queue is useful - I'd say the goal should be "reduce the queue to focus reviewers". What I mean by that is when we have 100+ projects in "needs review" the reviews are spread thinly across a random assortment. If there's < 50 projects, all reviewers will be forced to focus on those, and the quality will improve. 50 still seems like a big number, it's 1 page on d.o's pager, but maybe 25 is a better target.