Accueil / How we trained 120 people to be core contributors at the Drupalcon sprints

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:

  1. Add a modified simpletest framework to core. Then add enough assertions to provide test coverage of core. We currently have 19,930 test assertions.
  2. Automate testing of all core patches. See http://qa.drupal.org
  3. 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.
  4. 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.
Tweet off to the newbie room

  1. Download Drupal 7 development tarball locally, or check it out from CVS.
  2. 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.Acquia stack installer settings
    importing raw code base into stack installer
  3. You may run into one of five bugs with the Acquia Stack:

    1. 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".
    2. Installation does not complete on Windows. Point your browser to siteURL/install.php and it will complete
    3. The OSX installer only works on Intel based macs. Switch to MAMP for your PowerPC based Mac.
    4. 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
    5. 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.
  4. 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.
  5. Run one test. Configuration >> development >> testing. Select a single test and run it.
  6. Start the Simpletest Example tutorial.
  7. Download the Drupal 7 Examples project, and place the modules in sites/all/modules directory.
  8. 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.
  9. 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
  10. Drupal.org advanced issue queue selections for core tests that need review

  11. 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:
    1. Project is Drupal
    2. Issue tags "is one of" and "needs test"
    3. Status of "Needs review"
    4. 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.

  12. 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.
  13. drupal advanced search active or needs work issues tagged needs test

  14. 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.
  15. 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".
  16. 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.

Tweet thanking sprinters and commitment to continue

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:

  1. Over 75 contributors participated in the core issue sprint
  2. Jennifer Hodgdon helped lead the Drupal docs sprint
  3. Stéphane Corlosquet lead the RDF sprint
  4. Narayan and Derek Wright lead the infrastructure sprint
  5. Derek Wright lead a GIT sprint
  6. 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.

Commentaires

Posted on by yoroy (non vérifié).

It took me a looooong time to wrap my head around CVS checkouts, diffs and patching. You really have to tie quite a lot of concepts together before it starts to make sense. For anyone looking to get started, I documented how I got it all set up in Aptana (a distribution of the Eclipse IDE) http://www.slideshare.net/yoroy/create-drupal-patches-with-aptana

Posted on by ronaldmulero (non vérifié).

Kieran, great post.
Wish I had made it to the sprint. Now, I can't wait to take my first dive into the core queue.

Just a tip, though, for others like me who might be using this blog post as a guide to learning how to become a core contributor. Step 7 might be easier to understand if it read like this:

7. Go to Modules >> Example Modules and enable the Simpletest Examples module. Then go to Configuration >> development >> testing, open the Examples category, and mark the checkbox only for the Simpletest Example test. Note, do not confuse this checkbox with the checkbox of the SimpleTest category lower down on the page. The checkbox that you want to mark for this exercise is the Simpletest Example checkbox in the Examples category. If you don't see the Examples category, scroll to the bottom of the page and press the "Clean environment" button and the Examples category should appear.

Hope it saves another core sprinter newb the extra minutes it took me to wrap my head around this step. :o)