I had the pleasure of arranging for four individuals to present on the topic of Drupal oriented training at Drupalcon on March 7, 2009, in Washington DC. Barry Madore from Advantage Labs, Alex Urevick-Ackelsberg of Zivtech, Lee Hunter from the Drupal Doc Team, and myself from Drupaltherapy, all had about 15 minutes to weigh in on our experiences building building curriculum and training for the different wedges of the Drupal community. All of our presenters' notes are written up through their blogs, now linked from the session page on drupalcon.org.
My goals for the session were to provide some resources to the community to develop more Drupal training opportunities. There is a gradient of Drupal knowledge with both ends of the spectrum expanding. Our training opportunities should expand proportionally with the base of new learners entering the community.
It's such a broad spectrum but only a small scope of training has really been cultivated. I work and thrive in the entry level learning realm because I saw this as the area with the greatest need. I've been building a very successful model teaching concepts and best practices to new users and I've come to type cast them into a few general categories.
There are people that don't intend to ever use Drupal but need to know enough to understand its potential, like executive directors scouting the software to determine if it's right for their organization. There are people who have just adopted Drupal and have to acquire a new skill set before starting a project. There are organizational, educational, and business staff who found themselves using newly deployed Drupal web applications and need to learn only a tiny portion of Drupal to perform their jobs. And finally there are also small scale developers and/or web hobbyists who roll out a few small projects each year.
One of the points I wanted to drive home is what the process of Drupal skill assessment could look like. I make a point to interview new training clients to determine the amount of Drupal knowledge they have and how they learned it. Many times this includes determining what knowledge a client has to unlearn.
I don't have a linear process. Measuring a person's understanding of Drupal has not been, so far, a system of checking boxes or circling numbers. There aren't many other benchmarks set outside of Drupal that can describe their potential existing knowledge. People with a high degree of PHP knowledge believe they know a lot about Drupal, people with no development experience outside of their Flickr, Twitter, and Facebook accounts all believe they know almost nothing about Drupal - and neither scenario is necessarily true. Drupal is also a moving target that changes all the time - CCK is easy to understand, as an example, but how can we evaluate the potential for a learner to understand future changes in the project, like the Fields API.
It makes a lot of sense to first evaluate a learner's goals. This can tell you a lot especially if a learner is mid-project or task. Then once you understand the goals, you can determine how close to those goals the learner is already. And then build a training based on reinforcing concepts they already grasp and closing the remaining gaps.
I have a basic curriculum that covers the most fundamental concepts of the Drupal project, and I can reshape however a client needs. This comes as a result of answering requests for training in the same things over and over. I recommended in this Drupalcon session that consultants and development shops being to cultivate their own training programs based on the work they do, especially if their clients come from similar flavors of business. There is not only potential to serve the community knowledge void, but also the opportunity to maintain a recurring training program that add value and to their development work. The way I see it, keeping training as an afterthought is missing out on a lot of opportunities.
At some point in the Drupal learning process, after trainees hit a very specific point in the curve, every single one of them needs to branch or fork out in some specialized learning direction and meeting those needs becomes more difficult. That point comes right after grasping core and a handful of the really popular contributed modules. Here is where the other presenters picked up the thread.
Following my comments, Barry Madore of Advantage labs described their Drupal "study hall" mentoring programs in Minneapolis.
Alex Urevick Ackelsberg discussed his recent experience with training members of his fast growing Drupal development shop Zivtech.
Lee Hunter batted clean up with a discussion on developing documentation for training, particularly the difference between code-driven documentation versus doc-driven code.
There were several really good questions and comments to follow the discussion. Some great suggestions were made to aggregate our training curriculum into central places, and to develop standard Drupal certification programs (like we discussed in Szeged last year).
Unfortunately, we were one of the 9 sessions out of 100+ that did not get videotaped for the web. It may have been conspiracy, but its more likely that they put resources into the concurrent Fields API session happening in the room next to us.