How we trained 120 people to be core contributors at the Drupalcon sprints
In my previous post on Drupalcon innovations I addressed how we, the Drupalcon organizers, added a sprint before Drupalcon when contributors are passionate and well rested. This was one important part of growing the Drupal community. In this blog post I'll explain a larger strategy of how the community is training new community members to use quality assurance tools to improve Drupal sites. This sprinting has the side benefit of teaching people how to become core contributors.
I've been working on quality assurance for Drupal since Drupalcon Barcelona, when some of the biggest Drupal projects pulled Dries, Boris Mann, and myself aside and told us we need to raise the quality of Drupal and it's community contributions. Over the last three years, I've worked closely with Jimmy Berry, Rok Zlender, Kevin Bridges, David Norman, Damien Tournoud, Narayan Newton, and Derek Wright to develop, maintain, and deploy the automated patch testing system on Drupal.org.
Our current Quality Assurance strategy has four phases:
- Add a modified simpletest framework to core. Then add enough assertions to provide test coverage of core. We currently have 19,930 test assertions.
- Automate testing of all core patches. See http://qa.drupal.org
- Train developers how to clone their production sites and run tests on core, contributed modules, and their custom modules so that testing become an integral part of site development. See this webinar for details.
- Ensure that quality assurance tools are sustainable by getting organizations reliant on quality assurance tools for core, patch review, and their own sites to contribute back to the quality assurance tools development.
To help expand the base of potential contributors to the quality assurance tools development we first started with a Drupal.org front page announcement about a webinar for site building and the sprint at Drupalcon San Francisco. Over 460 people have now watched the webinar live or watched the video online. This helped to promote the sprint and get people who were interested in quality assurance for Drupal to attend.
13 steps to becoming a core contributor
At the sprint we segmented everyone who didn't yet have a core patch committed into a single room to help them get their first patch in. This provided a lot of structure to the sprint and allowed us to provide one on one support for learning how to write simpletests as well as how to become a core developer.
- Download Drupal 7 development tarball locally, or check it out from CVS.
- If it takes more than 5 minutes to get your local Drupal 7 development environment working stop and set up the Acquia installer available on Windows, Mac, and Ubuntu. This environment is optimized for Drupal. It provides many features to prevent you from making mistakes, including a GUI to import a Drupal 7 site. It is important not to get caught up debugging people's PHP environment as that distracts resources from the sprint. The instructions for importing a raw Drupal 7 code base can be found in the Importing sites documentation in the Importing Other Raw Code Bases section.
- The installer will not start because it has to be run as an administrator. Right click on the installer icon, and select "Run as administrator".
- Installation does not complete on Windows. Point your browser to siteURL/install.php and it will complete
- The OSX installer only works on Intel based macs. Switch to MAMP for your PowerPC based Mac.
- When you are providing the import site details you get an error about using the server name "localhost". Change the server name to anything other than localhost
- If you are using the acquia-drupal *.deb package, there isn't a GUI to import Drupal 7. Follow the recommended steps for importing Drupal 7.
- Enable the testing module. Modules >> enable testing. Note, do not download the Drupal 7 simpletest module, it already included in Drupal 7. If you do, re-install your site.
- Run one test. Configuration >> development >> testing. Select a single test and run it.
- Start the Simpletest Example tutorial.
- Download the Drupal 7 Examples project, and place the modules in sites/all/modules directory.
- Enable the examples module. Go to Configuration >> development >> testing and look for the Examples category and the simpletest example test. If you don't see that test, scroll to the bottom of the page and press the clean up environment button and the example category should appear.
- Open the examples simpletest module and look for the bug. Hint: It's the part of the module that has comments that say something like HERE IS THE BUG
- Once the simpletest tutorial has been completed. It's time to move to the core queue to look at issues that need tests written. You should use advanced issue search. In advanced search set the following search paramters:
- Project is Drupal
- Issue tags "is one of" and "needs test"
- Status of "Needs review"
- Priority "critical & normal & minor"
This will give us a list of simpletests for Drupal core that have been written already, but need review. Reviewing a test is a great way to get started. The test should be included in a patch towards the bottom of an issue. The test result should be Passed and issue should be green. Install the Dreditor grease monkey script to help with review of the patch. Read the reviewing patches documentation to help you provide feedback in the issue.
- Update the issue and change the Status to: "reviewed and tested by the community". At the sprint we then put patches that were ready for review on the white board in front of Dries and Angie for review and committing to core.
- The next step is to write a test for Drupal core. We can do an advanced search for Status of "Needs work" or "Active" to find issue that need a patch updated or started. If the solution isn't immediately obvious it can be helpful to ask the sprint organizer or someone near you for help.
- Once the test has been written, change the status to "Needs review" and notify the sprint organizer and they will find someone to review your patch, as you did for someone else in the previous step. Once your patch has been reviewed it will have the status changed to "reviewed and tested by the community".
- At the sprint on Thursday after Dries or Angie had committed the patch we held a little ceremony in the new contributors room to congratulate people who had their first core patch committed. We then took to the main core developers room and had a little welcoming ceremony there as well.
You may run into one of five bugs with the Acquia Stack:
Not everyone who attended the two days of sprinting has a core patch in yet, but they got an up close look at what it takes to become a core contributor. If we could replicate these sprints at Drupalcamps around the world we would be able to have a lot more core contributors and would be able to ship Drupal 7 even faster.
On Sunday Jimmy Berry, ran a tutorial during the sprint to help train new developers on how to clone their production sites and run tests against them. On Thursday, Jim Berry, ran 2 tutorials on how to use the coder upgrade module to port modules to Drupal 7. Both these tutorials helped expand the new contributors knowledge base for contributing back to Drupal project. A special thanks to Mike Meyers CTO of Examiner.com for sponsoring Jim and Jimmy's development as well my time to help build a sustainable model for testing tools.
These sprints wouldn't have been as successful without Jimmy Berry, and Randy Fay providing technical support for debugging the examples tutorial. A special thanks to Michael Haag and Joshua Rogers for help debugging the Acquia stack installer across so many different environments.
Critical core issues, docs, RDF, redesign, GIT, infrastructure, *.drupal.org upgrade sprints
We held several other sprints in parallel to the new contributor sprint. Sprints were held on the following topics:
- Over 75 contributors participated in the core issue sprint
- Jennifer Hodgdon helped lead the Drupal docs sprint
- Stéphane Corlosquet lead the RDF sprint
- Narayan and Derek Wright lead the infrastructure sprint
- Derek Wright lead a GIT sprint
- Several of the maintainers of the *.drupal.org sites sprinted to upgrade their sites.
Core maintainers sprint
For the sprint we started with 4 rooms but quickly had to expand to 8 rooms to accommodate everyone. We set aside a quiet room for the core maintainers so that they could focus on meeting core developers who had very complex patches which needed to be discussed. This allowed them to meet with a lot of groups of core developers and work through issues that needed some focused attention which might not have been possible in a room with 50 of more people.