Skill sets

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Open Curriculum: DefinitionsScenariosRoadmapSkill setsOpen certificationReferences - Roles
Follow discussions here on g.d.o, on IRC at #drupal-skillmap, or on Twitter with the tag #drupalskillmap!

Some sketches for Drupal skill sets

The image sources can be edited at The current map has been discussed and improved for a while, so it makes sense to discuss any significant changes before implementing them. Image is distributed under the same creative commons license as Drupal documentation.

Drupal skill set tree. Feel free to edit the image!

Drupal related skill sets

Skill set Description Comments
Basic skills Having a user account, being able to search issue queues and reporting bugs in a proper way, etc. Two important skills are knowing what to ask and how to ask it.
Community participation Includes taking part in discussions, attending in Drupal meetups, etc.
Active community contribution Doing things like organizing Drupal meetups, coordinating or actively contributing to community projects, maintaining (code) projects, etc.
Content creation and management Also includes managing comments, and scheduling publishing (where applicable), and so on.
Simple site configuration Includes managing menus, users, blocks, front page settings, etc. Changing existing settings, but not creating new site functionality.
Advanced content construction This includes managing content and presentation settings on the site, for example by configuring Panels, Skinr, Context, Simple Views and more.
Basic site building Includes installing Drupal, configuring fields, creating simple views, installing and setting up fairly simple modules (such as References, Scheduler and Automatic Nodetitles). It also includes being able to evaluate contrib modules.
Advanced site building Includes complex Views configuration, and complex modules such as Page manager, Rules, Organic Groups and access control modules. And Commerce. This area might be too wide, but I don't think it makes sense to break it up into smaller pieces //Itangalo
Multi-site installations This includes managing multiple Drupal sites that in one way or another share content – such as sharing some data tables on a multi-site installation, using Domain Access or doing advanced site building with Organic Groups.
Multilingual sites Setting up multilingual sites, knowing the relevant modules, and adapting configuration of other modules accordingly.
Configuration export Taking Drupal configuration and turning it into exportable, importable and version-controllable code.
Basic theming skills This involves installing themes, creating subthemes, and tweaking sub themes with CSS and custom template files.
Advanced theming skills This involves responsive web design, grid based layout techniques, jQuery based interactions
PHP coding for theming This involves the basics you'd need to know of PHP before learning Drupal theming.
Front end development This includes developing base themes, writing layout plugins to contrib modules, optimizing front end performance, declaring new renderable elements, developing for modules like Skinr, using AJAX, AHAH and other techniques for creating good user experience. Writing theme functions, preprocess functions, form_alters, adding/changing theme settings and using the show/hide functions.
HTML5 web apps Being able to use HTML5 technlologies to build app-like pages for mobile browsers, possibly to embed them as downloaded apps with PhoneGap (or something).
Basic Drupal coding skills This involves PHP skills, knowing Drupal coding standards – including writing well-commented code, using hooks and using Drupal's API to write secure code. It also includes using Drush. Maybe Drush should be moved somewhere else. //Itangalo
Coding for major contrib projects This involves writing Views plugin/handlers, as well as understanding or extending other important parts of the Drupal ecosystem.
Knowing enough about even advanced core concepts – such as access control, rendering layer and DBTNG – that it is possible to write and review non-trivial core patches. Knowing when and how it is ok to hack core. (Wow.)
Secure coding Secure user input, XSS, Form API Security, etc.
Web services and native movile apps This includes using Services and REST, integrating with external APIs, and being able to expose data to consumers like mobile applications.
Basic performance analysis/optimization This involves things like setting up caching rules, being aware of performance impacts of complex architecture, etc.
Setting up Drupal servers Includes all server-side setup for getting a Drupal site running: web server (Apache), database, PHP, file permissions, etc.
Automated testing/continuous integration Being able to write automated teseting for Drupal functionality, and implement the tests during development. Involves SimpleTests, but possibly other testing technology as well.
Content migration Migrating large sets of data to a new site, including both database entries and files. Also involves leveraging contrib modules for migration.
Site maintenance Knowing how to update modules, doing backups, watching for security releases, etc.
Advanced performance optimizing This involves dealing with load times, memory usage, slow queries, identifying memory hogs, setting up reverse proxy caching, changing cache layers, etc.

Skill sets not depending on Drupal

Git skills Involves things like setting up Git repositories, cloning, branching, merging, plus creating and applying patches. Incorporate in "Basic coding skills"?
Documentation and training This is currently a stand-alone skill set, since documentation and training can be added to any of the other skill set. This skill set might deserve being broken up into smaller parts. //Itangalo
Content strategy
Task analysis Is this a part of interaction design? Or is the area useful in itself?
Visual design Defines the visual language of the Drupal website in accordance with the stakeholders' goals and existing brand. This includes, but is not limited to, font treatment, layout, colors, imagery and overall graphic style. The visual design work is often delivered in the form of a style guide and one or more comps-- usually in .PSD or similar format.
Interaction design Defines the workflow for website users as they interact with the website to perform specific tasks. Often times, this work results in wireframes or prototypes of specific pages and or interactions based on a given user story.
User assistance Provides information to help a person to interact with software.
Information architecture Analysing client information and processes to facilitate design of intuitive navigation, content types and site structure. This needs a description. Risks overlapping with "requirements gathering"?
Usability testing Performing testing to gather information about usability problems, as well as verifying good effect of interaction design. I suggest using usability testing instead of usability research!
Web strategy Description needed! (Should this be moved to project management?)
Requirements analysis Capturing end results that clients wants, and describing these in development terms – and communicating with the client about both of these. Also includes listing (internal) competence requirements.
Roadmap Planning and replanning project process, including milestones, large project subtasks and staffing planning. (Please correct me if the description is wrong!)
Market analysis Involves identifying market segments and individual companies/organizations that are good potential clients. (Please correct me if the description is wrong!)
SEO strategy Involves analyzing own or client's needs of marketing through web search results, and making plans for satisfying those needs. (This description is mostly my mumbo-jumbo. Please update if you got more to say.)

What is a "skill set"?

The point of describing Drupal skill sets, is to make it easier to see what skills are needed – and which skills are shared between different roles of Drupal professionals. ("Professionals" should here be taken as people working with Drupal in one way or another – not necessarily as their job.)

Here, skill sets are characterized by the following properties:

  • Skill sets describe sets of skills, describing what you are able to do – not milestones or achievements showing what you have done.
  • Skill sets should be fairly broad, covering a several related skills – "managing content" is much better than "creating a node".
  • All skills covered by a skill set should be related to the same kind of Drupal work – skills for managing content shouldn't, for example, be in the same set as skills for contributing patches.
  • Every skill set should be separate from other skill sets (or, realistically, minimal overlap with other sets).

With a good collection of skill sets, it should be possible to do the following:

  • An expert Drupal user of any kind looking at the list of skill sets should feel that the relevant sets can be used to describe her competence fairly well (while some expert skills may still not be covered by the list)
  • A Drupal user of any kind should be able to look at a list of skill sets and identify which ones she has covered
  • A Drupal user of any kind should be able to look at the list of skill sets and identify skill sets that borders to her current competence
  • An employer for Drupal talent should be able to describe the talent she is looking for by mapping it to the skill sets

Skill sets and roles

The skill sets above could be assigned to different roles for people working with Drupal. One way of doing this is described by the image below – but this should only be taken as an example (since roles and tasks vary between projects and Drupal shops).

(See this page for more discussion about roles. Suggestion: Move the role discussion to another page. //Itangalo)

Drupal skill sets, by role. Feel free to edit the image!

Current important tasks/questions

  1. We need more details descriptions of the skill sets!
  2. Are we missing any important skill sets?
  3. Some skill sets – in particular "web services and mobile" probably needs to be split up
Drupal subject areas (sketches).png36.57 KB
skills-and-roles-top-down.png116.17 KB
skill-tree-squared.png174.11 KB
skill-tree-squared_4.png175.3 KB


Great stuff here

JacobSingh's picture

I love this discussion. We're having similar internal discussions at Acquia on what it means to "know your stuff" to come work for us. It's tough. I would say you're on the right track. In response to specific questions:

Q: Does it make sense to use subject areas to describe Drupal skills? For all role skills?

This is what I keep coming back to. Although we can make up several subject areas, when we are designing curriculum, the end goal is important. And that end goal for job seekers (learners) and for job providers (hiring firms) is for the student to be qualified for a role. While those roles deviate from place to place, I think we can make some general assumptions about what they are. Roles, unlike subject areas overlap heavily. For instance:
Only local images are allowed.

(btw, if you want to edit this).

I find it easier to think from the top down "what do you need to know to do job X" than the bottom up "here are all the things there is to know".

Top-down +1

Itangalo's picture

Yes, it definately makes sense to use a top-down approach on this one. (I should probably change the table to reflect this – and using your Cacoo diagram instead of the mind map-thingy also makes sense. Thanks for the link!)

I'd like to stress that the subject areas should not only be useful for employer and job seekers – but for anyone who'd like to assess and/or improve her Drupal skills (including hobbyists). You're not saying otherwise, but I just wanted to make it explicit. :-)

I think I have pretty good insights into site building and content editing – but I have basically no idea what skills are needed for theming or project managing. Anyone who wants to take a stab?

//Johan Falk

Refactored the tables

Itangalo's picture

I just refactored the tables, to give a more top-down approach. Now each role is described with a list of subject areas, and the subject area descriptions have their own table.

While doing this I realized that it is pretty difficult to say that a site builder "should" know how to make multilingual sites, for example. There are skill sets that clearly belongs to one role, but (IMHO) shouldn't be required in the role. I have for now marked those with "/" rather than "X". There were also a lot of question marks.

I don't think we need to agree on whether certain subject areas belongs to a role or not – what is important is if it makes sense to talk of a specific subject area. Then there may be site builders with a particular skill profile, and other site builders with others. (As a later step it would be nice to get more clearly defined roles, but I don't think we need it right now. Eventhough it might be desired.)

//Johan Falk

PS: I also removed the mind map image. (It is still attached to the wiki page, if anyone wants to see it.) I'll give priority to building up a better image, using Cacoo, since I think it is important to have an image to get a quick overview of what this page is about – it is quite text heavy right now. But now I'm off for a party! Yay!

Edit: Image updated! It even replaced the large table of roles and subject areas, which feels like a relief for this page.

Outdated image at cacoo?

anoopjohn's picture

It looks like people have edited the original image at cacoo and the image listed at the above URL is no longer aligned with the skills set diagram. Is there another source format for the diagram?

"Be the change you wish to see in the world", M. K. Gandhi.

Another Vote for Top-Down

karenfreemansmith's picture

I'm still pretty new to Drupal and learning. I have to agree with the top-down approach. The "everything you could possibly do" is overwhelming when you are new and learning. I'd like to see more task-oriented training.

Karen Freeman-Smith
Eugene, Oregon

Heya Karen - If you'd like to

heather's picture

Heya Karen - If you'd like to work on (or share thoughts on) learning materials development, and specifics of teaching methods, please do check out the Open Learning and Collaboration Portal

Added tips from Bojhan Somers

Itangalo's picture

I had a quick e-mail conversation with Bojhan Somers, which made me add three new subject areas related to Design & UX.
He also gave me a link to Assessing Your Team's UX Skills, a blog post by Jared Spool, that I think can be really useful for expanding on these subject areas. I haven't yet read all of it, but I hope to get back with more descriptions of what the new subject areas means. (If someone with more design/UX experience than me is interested, please go ahead and beat me to it!)

Very cool! Thanks for pushing

linclark.research's picture

Very cool! Thanks for pushing this along :)

  1. In my mind, Community Participation seems like a case of "one of these things is not like the others". The other roles can be pursued in a pretty much mutually exclusive way, while all of the other roles participate in the community... and I think we want to highlight how central community participation is to being really skilled in any one of these roles. I'd like to see those skills peppered throughout the tree.
  2. Is there a set of 'content management' skills that are distinct to Drupal? I've never really thought of that as something that required specific Drupal-y knowledge. Instead, I think that anything that is Drupal specific would fall under the category of site building. While there are things to learn about being a content editor generally, I don't know if we should try to cover them. Happy to be contradicted on this, I don't have a strong opinion.
  3. We may want to rethink using gendered cartoon people as representatives here... I know this is a function of the options available in Cacoo, but I think we should be aware of it since old stereotypes have a way of creeping in subliminally wherever they have a chance to.

    One thing that happens to a lot of women when they walk into open source dev discussions is they get asked "are you sure you're in the right place", which makes many women turn around even though they were in the right place to start with. While Drupal is generally better about this, it does still happen... for example, one woman who maintained the original module for a certain kind of system, then went to a BoF on the topic a few years later, and was asked if she wasn't looking for a different, non-technical BoF. Having a gendered cartoon to typify the role reinforces the mental picture people have of a certain kind of expertise and who they expect to have it. For some of us, that mental image doesn't fit so well :)

    Maybe we could try to switch to non-gendered representations as soon as we move past the ideation in Cacoo. Or upload our own set of neato cartoons to use.

I would put "Community

heather's picture
  1. I would put "Community skills" as a horizontal across certain roles:

Site building
Project manage/planning

These people need to know how to find their way through project pages, issue queues, etc. For example a project manager matching requirements to drupal implementation; or a site builder testing patches or -dev versions of a module, and commenting on issues queues.

  1. Content editors, in my opinion, have a need to understand Drupal- simply for the fact they need to know how to communicate with their developers. I think some fundamental knowledge of how Drupal works would help them.

  2. You can edit the cartoons in cacoo, and remove details like ties, hair, etc. So we could have generic baldies... is that better? Maybe animals?


Itangalo's picture
  1. Yes, I agree. "Community participation" is not a role in itself – as far as I know, there is noone who is "only" a community participator. Also, as both you and Heather point out, these are skills that all roles would make use of. I'll restructure the diagram accordingly. (This is also a good case for using the salad bar approach, as suggested by idcm below – see more comments there.)
  2. I do think there are specific content management skills in Drupal. Specifically, I think about finding nodes and comments, and publishing/unpublishing them, and things like customizing teasers. (Other CMS obviously have corresponding workflows, but knowing how this works in Drupal is a particular skill.) You might also add taxonomy management to this – even though it maybe bordering to "basic site configuration".
  3. Cartoon people now replaced with Druplicons! (I swear that I didn't plan to match gender and roles in any way – I placed the people first and then listed the roles in a previously given order. But I noticed it was kind of stereotypical too.) However much I like the Druplicon, I actually think that the diagram lost some "personal" feeling – there are no longer real people represented at each role, just an icon. Do you think it would be fair to have female-only cartoon people? (It would be an obvious bias, but men are overrepresented in so many other places that they/we shouldn't complain.)

I agree that it does loose

linclark.research's picture

I agree that it does loose some of the personality. Unfortunately, if we use all female cartoons, one probable side effect would be that it causes such a stir and such animosity that it only makes women feel even more uncomfortable, I'm afraid.

An idea I had on the way to work was to make the Druplicon really fun, like Morton DKs bug Druplicon... if we had the right illustrator do it, I think it could be really neat and the Druplicons could still lend a lot of personality.
Only local images are allowed.

Another thing we should be wary of (besides gender) is using cultural markers of status or class... like making one look smarter than another. I think we can do this by having Druplicons that speak to the action performed by the role as opposed to the cultural markers usually associated with people who hold the role.

Some quick, rough ideas for what these Druplicons could be made to represent... I have no attachment to these ones, just some thoughts:

Content editors
Drupalicon made of a calligraphed D, like the "D" in the following except it would be way more Book of Kells
Only local images are allowed.
Site builders
Druplicon made out of legos
Only local images are allowed.
Of course, the obvious idea is Matrix style, though might be played out by now
Only local images are allowed.
Mondrian style, referencing grid based design
Only local images are allowed.
Systems architect
Blueprint Druplicon
Only local images are allowed.
Project management
Cat herder? This could be really fun, Druplicon with a cowboy hat and lasso with kittens running by
Only local images are allowed.
Don't have any ideas for this one yet

OMG we need an

heather's picture

OMG we need an illustrator!!!

GREAT ideas!

  • h

We're up for it

alemadlei's picture

Hi, my business partner and I would really like to help out.

We work with the Drupal community here in Costa Rica. Here are a few designs he has done for the local Drupal meetups.

Let me know if we can help out.


Nice graphics

Itangalo's picture

Those images look really nice. Just saying.


alemadlei's picture


Let us know if there is something that eventually we could help with.

Excellent imagery. A while

idcm's picture

Excellent imagery. A while back, others in the community attempted something similar to what you are doing. Although the roles perspective is very helpful, you run into what you point out - roles vary from organization to organization and their responsibilities vary as well.

I proposed an alternative here I strongly believe you need two perspectives and that tasked-based subject areas should lead with role-based planning taking the second seat. Think of it as a salad bar. Because the ingredients are in separate bins, you can build your own salad. Pre-made salads tend to be just shy of what you really want.

The role-based strategy definitely has a role in the planning of an educational experience. All training needs an audience to help focus the scope of the task, the perspective of the task. But as you can see, not all training is specific to one role. As a person building a career, use maps like those provided above to help you pick and choose the learning experiences you might need but also pay attention to job ads. You never know when someone wants an all-in-one or a specialist.


I agree

Itangalo's picture

When working with the subject areas, I have been thinking more and more as you describe – we need a task-based approach as well. The roles listed above probably maps pretty well to most people working with Drupal, but very few will find a perfect match. Having a salad-bar approach makes very much sense – from many perspectives (describing your skills, finding things to learn, hiring people, creating Drupal training and more).

However, I also think that the role-based approach really helps in finding and describing subject areas. I now call the diagram "Drupal knowledge subject areas and examples of mapping against roles" – which I hope will make clear that this is one way of combining skill sets.

I'll see if I can make a sensible diagram of subject areas that doesn't involve roles – using something similar to the mind maps used previously. That approach could also illustrate that some subject areas build on otheres (as well as, hopefully, make it easier to find subject areas close to your current skills).

EDIT: There is now a tree-like thing for subject areas, described independently of roles. I'm not sure I would classify it as a "sensible diagram", but it could hopefully be improved later on. Only posting an image link here – not the image itself – since it would risk slow down the progress. (Which is actually going quite well!) image link – source

I saw your mindmap /

idcm's picture

I saw your mindmap / relational flowchart in a previous post. I like that as well as it shows some of the relationship between subject areas. That is helpful. Maybe consider including both perspectives in the wiki post?

I agree

moose1186's picture

idcm, I agree that using both perspectives will be most helpful. Also agree that the mindmapping is a great way to show the relationship within subjects.

Added to Design and Theming roles

pixelwhip's picture

Excellent work. This will be useful in a number of cases. I added descriptions for Visual Design and Interaction Design.

I also added the Design Implementation skill to Themer & Front-end dev. role. I see this as the primary skill for themers and didn't feel any of the other skills represented it well. Theming and front-end dev. also require basic coding skills. I updated the chart to reflect that as well.

Break up into several?

Itangalo's picture

Sweet addition! It was really needed.

Do you think it makes sense to break up "design implementation" into several, more descriptive areas? I don't know theming enough to be sure, but maybe "(X)HTML+CSS+JS+JQUERY", "customizing templates/theme functions" and "browser testing" could be useful?

For this to be useful, though, these subject areas should be useful by themselves – not just in combination. (Maybe this excludes the last one, that should be a part of the first?)

Feel free to change/update the image if you think this makes sense.

Prerequisites v Drupal skills

heather's picture

We should be careful to limit the scope to Drupal specific skills.
Other skills ((X)HTML+CSS+JS+JQUERY) are pre-requisites. We're not defining a job description. That truly is up to the employers.

If you would like to talk about pre-requisites we have this in the docs:
Skills of a successful front-end web developer
Back end:

However I think employers would be a great place to start w verification.

Next step: Verify in the wild!

heather's picture

I think this is in great shape right now. There are certainly some things popping to the top level that I would chunk under site building (e-commerce) or developing (configuration export).

As Cindy alluded above, we did attempt this last summer. However, I am confident I can say that the level of minutiae at which we were attempting this was far too detailed. Nutshell: trying to write assessable competencies. I feel strongly that we should avoid that honey trap at this stage. We should be careful to keep in mind we're not talking about a syllabus, learning materials or sequence of activities. I say "stop here".

We should recognize this is a real milestone. We could sit and chat for months probably about the details of each role/subject area.

On the Roadmap, we identified that we need to verify this in the wild as part of this first phase.

I think we should move onto that the verification, instead of hypothesizing further. (e.g., bikeshedding).

Into the wild +1

Itangalo's picture

Amen. It is time to get outside verification that we're going the right way.

I'm gonna do the following:

  1. Make some updates to the subject areas that I think makes sense: (a) Move "content creation" into content creation, and rename it "content creation and management". (b) Remove content migration from the content managing role – while content managers could do manual migration, it is not what is meant by this subject area.
  2. Have a live chat at IRC, if possible. Time will be decided in this poll!
  3. Hopefully make a sketch for subject areas not listed by roles. (Though this is not necessary for going into the wild.)
  4. Prepare a blog post for Drupal Planet, encouraging people to review and comment. And provide some guidelines for doing this. (I'd be happy if someone else did this – Heather? – but I'm also happy to do it my self, or co-writing it.)
  5. Start a new page where the discussion could be held. (Or should we use this one? I think we'll see quite a bit of comments.)
  6. Wait at least 24 hours before posting to Planet, to give anyone a chance to make updates they think should go in.

I would be happy if you (yes, you!) could do the following

  1. Write one or more descriptions for subject areas – there are still several that lacks this.
  2. Make any additions or changes to the subject area list that you find are in order. (If you don't have time to update the diagram, just post a comment and I'll take care of it.)

Rock on!
//Johan Falk

Heather is right. The last

idcm's picture

Heather is right. The last attempt did get into a lot of detail and that is a potential trap that can be sprung with either perspective. Like I said, great imagery. I like the way they convey the perspective.

Awesome awesome awesome. I'm

yoroy's picture

Awesome awesome awesome. I'm working with heather to see where this overlaps so we can join efforts where possible. Very insightful material, agree it needs to be verified in the wild now.

IRC live meeting this week

Itangalo's picture

I think it would be useful to have some live discussions before sending this to the wild. I've set up an Event node at, with a Doodle poll for time at

Notes from the meeting

Itangalo's picture

Notes from the meeting can be found here:

The short-short version:

  • Roles will not be discussed during this round of feedback. We start with the skill sets, and build from there.
  • Also, skill sets that are not specific to Drupal will not be discussed during this round of feedback – again to get some core things done and build from there.
  • There will be a list of concrete tasks set up (such as taking on individual skill sets for more detailed descriptions, or do interviews to get feedback on the skill sets). That list is not yet written.

Front end engineering, and other roles

batsonjay's picture

The approach above looks at the process as it is today: "developers" build modules, and "themers" make them look a certain way. I see two shortcomings in this description:

  1. Web 1.0 interaction style. That subject areas listed above presumes "Code produces HTML that is themed." Instead, user expectations are changing to interactions that are more Ajax-oriented. I no longer want to push a button that refreshes the page for a confirmation, then refreshes it again with results. I expect to push a button, have little if any confirmation, and see the page change in-place.

    So IMHO it's short-sighted to describe "design implementation" as "building a theme." Instead, don't we want to grow a class of "front end engineers" that build Javascript, jQuery, and other methods of user interaction? If so, do we cram that definition into the design implementation subject area, or create a new one?

  2. Mobile. Nowhere in here do we handle issues around mobile. You can make the case that "It's just another part of ___," but I don't think I agree. Multi-lingual or e-Commerce could similarly be said to be ".. just another part of __", but they (rightly) need distinguished as unique.

I think there are two other subject areas that might not be represented well here:

  1. Page manager. Drupal needs to (and will) provide better tools for people that live somewhere between a site builder and a content editor to build pages with a unique layout and bunch of content. There's a discussion underway here about this (though I don't think they yet have talked much about this role..). Consider this person like the section editor of a newspaper or magazine - e.g. somebody who owns what the "sports section home page" looks like at the website for a city newspaper. They probably want this page layout & content collection to change when the NFL playoffs start, or if a basketball strike starts, etc. They may want different blocks (in a generic sense) of content to surround the hero image block for the duration of the (playoffs | strike | ..), and don't want to call a developer / themer. And they don't want to be an expert Drupalist that knows how to build Panels pages.
  2. Non-creator content influencer. The entire subject area set above ignores workflows. In organizations that have requirements around legal, or other restrictions, often content can't "go live" until it's passed a review by lawyers, marketing or PR people, or some other person who influences the content's display, but who may not actually edit the content.

I thought I'd open these thoughts up for discussion before I just changed the wiki page to reflect this. So, comments?

Design Implementation may be the wrong name.

pixelwhip's picture

Based on your comments and those above, Design Implementation may need to be broken up or renamed. When I first added it, I didn't feel like it would encompass Javascript, so much as CSS-- so maybe it's not the right term. When I think of theming, I think of adding the visual style to a site or application-- regardless of whether the markup or data is served up via full page requests or AJAX. It seemed silly to put Theming as a skill of a Themer / Front-end Developer. Themers gonna theme! Design Implementation came from lack of a better term.

I feel the Interaction Scripting (can't think of better term, which is why I didn't add it earlier) you are speaking of is important and should be listed as an additional skill that applies to both the front- and back-end developers, as shown in the diagram.

Front-end Engineering

rupl's picture

I agree that "Design Implementation" needs to be split up into several categories. Not only can you theme for distinct contexts (desktop, mobile), but oftentimes there is specialization within a group of themers. Jay hit it on the head with "front-end engineering" - it's not quite mainstream yet, but notable chunks of the server-side web are jumping ship and finding a new home in the warm embrace of client-side.

+1 for mobile.

Mobile is a specialization under the "Theming" umbrella today, but will grow to be much larger in the future, eclipsing many components listed in the top post. Mobile web development is not a satellite skill unrelated to Drupal; there are very specific pieces of Drupal's framework that you have to completely sidestep or (in the future) configure to be genuinely mobile friendly. People would benefit from both general awareness and the chance to learn how mobile websites are responsibly implemented.

Had a hard time describing it

Itangalo's picture

At the IRC meeting yesterday we tried to describe a "mobile" skill set, but couldn't find a way that didn't considerably overlap with other skill sets. Probably this reflects the fact that mobile is a satellite skill, as you say, and that nobody at the meeting had worked very much with mobile.

The "design implementation" skill set was broken up into three separate skill sets (see table above), and today the "advanced theming" skill set was renamed "front-end engineering" – and its content will be broadened. +1 to batsonjay for making this happen.

The feedback process will start any hour, and I hope it will make it easier to find weak spots and expand on the material we got. Suggestions about "mobile" skill set – how to describe and place it – are particularly welcome. (Both here and at the feedback page.)

//Johan Falk

-1- I agree that roles may

Itangalo's picture

I agree that roles may shift between companies, and you may be right that the diagram represents a kind of inside-the-box thinking. However, I think it is more important to focus on the subject areas at this point – it should be possible to use them for describing up just about any role you'd like. (In the best of worlds.)

I have added a "subject area tree", replacing the prevous role-focused image on this page. Hopefully this will make it more clear that the roles are just one way of using these subject areas. (We can definately discuss how/if roles should be described, but I'd like to get the subject areas ready for verification first.)

Good points about the "theming" skills. My expertise lies almost completely in site building stuff (and I haven't done mobile), so I can't really help with naming describing and placing these potential new subject areas. I'd be more than happy to help getting them into the diagram and descriptions, though. It seems there are theming-skilled people around, so I'll let you discuss this and find some good subject areas.

The way I organized it

dianamontalion's picture

Oooh, it is so exciting to see how this work is intersecting and growing as one body. Yeah!!

When I approached this, I had three main questions in mind: "what is the framework for professional development in this field, what would a longer-term curriculum look like?"; "what are the skills our team needs to have collectively and how do we identify areas of expertise?"; "how do we compare apples-to-apples when hiring and what are the most-necessary skills?"

This list was created collectively during (robust) meetings that included all roles. It was interesting to see how people with skills in an area (CSS, for example) struggled to identify "beginner" skills. People learning those skills were better at that part.

We (Four Kitchens) all agreed that the most important skills aren't the teachable ones. They are the person skills. I interviewed top Drupal peeps for the London session, asking them what the top skills they value are - and they all said the same thing. Person skills. That was a gratifying surprise.

The handout of skills is much shortened, I am expanding. I'm also looking at how to integrate that into this work here. (Yeah!)

Levelling up...

kattekrab's picture

What I particularly like about @dianadupuis approach is identifying three tiers to each skill.

This is really important. Acknowledging basic entry level skills, and differentiating those from the higher levels that come with experience is very valuable. Learners can assess their own level, and identify what they need to work on. Those folk assessing or evaluating someone's skill set can determine if they need top level talent, or if someone is on the right path and ready to learn and progress to the next level.

The grey area between basic and advanced is in some ways the most interesting, because it will be the hardest to define. Keep an eye out for stepping stone skills, and combinations of pre-requisite skills.

Donna Benjamin
Board Member Drupal Association


Itangalo's picture

I agree completely – having skills at different levels, and describing ways to climb the levels, is a really good thing. (And yes, I found that a really good thing in dianadupuis' approach too. And there are more things to learn from her presentation as well.)

Heather and I did some updates to the road map yesterday, and there is now a bullet for describing "levels" or "sub skill sets". We'll have to see what people are interested in working on, but I'd definately vote for this one. :-)

Advanced content creation

Itangalo's picture

I talked some with batsonjay about the skill sets on this page, and one of the things discussed is that there should be a skill set for "advanced content creation" – meaning creating layouts, sections and (for example) presentation-related stuff. This is certainly more advanced than standard content management, but it only partly fits into "simble site configuration" and "basic site building".

The problem with adding that now, as I see it, is that it doesn't map against anything that exists in Drupal right now. It is a necessary skill on most large Drupal site, where editors or super-editors need to be able to change front page layout, insert new ads, and do other structural/presentational changes to the site – but it all requires customized site setup first. Thus, it becomes a site-specific skill, and not something generalized to Drupal at large.

As batsonjay pointed out, this is actually a weak point for Drupal, not least since many other systems do have standardized ways of managing "advanced content creation".


Simplifying chart creation :-)

davidinnes's picture

"...this is actually a weak point for Drupal, not least since many other systems do have standardized ways of managing 'advanced content creation'."

I think this is another cool byproduct of the high-level schematic approach. Rather than parsing out how exactly this or exactly that should fit into this or the other box you start seeing that we need to build a few more boxes.

Advanced content creation, definitely. Mobile almost certainly (especially with Amazon's new cloud- and non-cloud Kindle offerings escalating the tablet wars.) Those are the ones plaguing me at the moment but there are others.

I mean, yes, we can fan out particular responsibilities across existing skillsets and roles to work with existing UI and features but it's probably more productive to encourage new UI and features so those responsibilities don't need to go into the skillset charts in the first place.


p.s. Meanwhile this whole project solves a very large training problem I've had for relatively small clients. It helps clarify what the owner/manager should know, what their employee or employees should be able to do, and when they should call me. And, of course, it'll help me personally whenever I need help from a collaborator, consultant, contractor, or (maybe some day) new hires. So thanks! This is all very helpful!

It may be a weak point, but it's not impossible

batsonjay's picture

For example, we have the following things today (in increasing complexity order):
- Skinr plus a 960-based theme permit people to change widths, number of columns, etc.
- Core blocks sit in those columns
- Context, boxes and views boxes can be used to make different core block layouts at different URLs control block appearance in more sophisticated ways than core blocks
- The Composite Layout module, or node-in-block style modules, or other similar modules can be used for layout
- Panels
- Etc.

A content creator with advanced training can do plenty of layout today. Granted, IMHO most of these are early attempts at providing this kind of functionality, and we need much advancement here. But I believe this is a commonly-held role that is separate from "site building". Many many customer of a site builder hold this role daily. The site builder comes in and sets up a site with Skinr, or Context, or Composite Layout (or all), and after they leave, the site content creator decides he/she wants a new page with a new layout and collection of blocks, and creates it. But it takes special skill for this person; they are not simply creating new nodes.

So, I still assert "Advanced content creator" is a valid role now - not just some time in the future.

I'm convinced

Itangalo's picture

I am now convinced that we need "advanced content creation" as a skill set. Thanks. And I'd also like to add things like creating webforms and making SimpleViews to the set.

The "simple site configuration" set seems rather feeble next to "advanced content creation" – would it make sense to merge it into the bigger one? Otherwise I suggest placing ACC after SSC but before "basic site building". Makes sense?

Thanks again for making me see that this skill set is needed. (And shout out if you don't think it should be added!)

To me it makes sense to wait with adding new skill sets until more feedback has been collected – it seems we will have to add a few other skill sets as well.

I agree with you, Jay. I have

mlangfeld's picture

I agree with you, Jay. I have built Drupal sites, though I do not (yet) program. I have built simple Views, am learning to theme with Fusion and Skinr, so am in the mix, not quite as advanced as Jay's example, however moving in that direction.

I also am now working in a large multi-site migration team (moving sites to Drupal), as a web editor/migrator. I had site migration under content management in an earlier version of the diagram, and would like it restored (it was removed), since on an enterprise site migration there's still a lot of editorial work that isn't scriptable. We're planning to migrate 40 sites in a year with this contract team of eight. As sites grow, content migration requires editorially-focused migration teams as well as development teams.

Best, Marilyn

Content migration is still

heather's picture

Content migration is still included in the diagram.

It is "after" basic site building skill set. And in closer conceptual proximity to site maintenance.

Are you recommending that someone can conduct or manage content migration without knowing much about basic site building?

Hi Heather! I didn't mean the

mlangfeld's picture

Hi Heather! I didn't mean the placement was wrong. It seems fine to me. And I certainly didn't mean someone can conduct or manage content migration without knowing much about basic site building.

In the color diagram, I added content migration to the content management track, then it was moved over, meaning content editors/managers wouldn't have a part in it. I'm seeing that on big migrations content editors/managers will be working very hard alongside developers to migrate content into newly created sites. I've partipated in two so far. One where all content was rewritten, all assets freshly uploaded; the other where nodes are being migrated by script, assets by script and editors; with editors creating nodes for many publications (files) one-by-one.

Not specifically a Drupal skill, but a task to be done in a Drupal migration that will be facilitated by Drupal knowledge. Or so it seems to me.

Best, Marilyn

another vote for advanced content creator

Joe.Cafiero's picture

The role of "Advanced content creator" is one I need to play at different depths on different days -- depending on the specific task, I range from fairly equipped to fairly baffled. I'm not a programmer or themer, not even a front-end developer ... but I deal with a lot of volatile content that is constantly requiring new variations. A lot of what's required seems like work simple enough for me to do on my own, but I've chewed up a lot of my time and my support programmers' patience learning what I need from them in dribs and drabs because I've not been able to find this kind of information presented systematically anywhere.

Hello Joe! I wonder if you

heather's picture

Hello Joe!

I wonder if you can describe the types of Drupal-specific tasks you or colleagues need to complete?

"Advanced content creator", is this person also creating pages of content, editing views, etc?

What do you mean by "volatile content".

I have thought of the learning needs of this role. We've created end-user training before, and I hoped I was going to find some common-ground. But looking into our own client needs it seems everyone has a different backend, and custom administration tools. Or some sites lack any kind of administrative customization. On top of that, each site has its own (or lack of) a workflow arrangement. Adding to that any complex specifications in terms of making sure there are node references or taxonomy terms, etc.

Much of that seems so custom and circumstantial.

Maybe you can tell me more of what you are thinking. I think I might be misunderstanding.


wfx's picture

I can't speak for Joe but at least where I work "volatile content" is content which has PHP or javascript code on a page you have to tiptoe around (don't overright the code or let the WYSIWYG editor meddle with it) so you don't break a page.

Where I work, my job title is "Web Content Producer" but "Advanced Content Editor" could fit too.

My job entails:

Writing content for web pages -
- product or service information pages
- software installation instructions. Often this involves consulting an IT resource in our department who has sufficient knowledge to collaborate on documentation.
- Create or find images to display on product pages
- Create news articles about events, outages, or other IT related happenings
- Find videos to add to tutorials or create my own and upload
Editing web page content
Creating / Editing views
Enable / disable / uninstalling modules
Theme development
Troubleshoot error messages

For me "Advanced Content Editor" gets murky because I research, write, and publish pages but I also handle a lot of the admin side of it too. The best summary for what I do is "PHP enabled" but not necessary "PHP proficient". I think this kind of mixed role is common in Universities where IT budgets are slim so often the person adding content quickly becomes "the Drupal person" who is asked to know all things Drupal and fix things when they break.


Wow - I really like Web Content Producer

batsonjay's picture

The word "producer" bring to mind a TV show producer, as it might for others. This brings to mind two ways of thinking about the role:

  • It suggests that this person (you) is the overall person responsible for getting the deliverable out the door; but that you may involve other contributors - just like a movie producer. You may get somebody to build you graphics / art, you may get somebody to give you info about products, etc., but you're the one who is responsible for pulling it together.

  • Often times there will be a "Web producer" who partners with the video producer, but who handles the online content. On news-like sites, where there's not a lot of pixel-perfect graphics design needed, this producer often has page layout control - deciding what blocks on what page, where, etc.

I'd be willing to go with the Web Content Producer title if people prefer it. I kinda like it.

Does this come close to describing you?

batsonjay's picture

(though it's a woman, and a different industry, does this sound like you)?

Advanced Content Creator

wfx's picture

I only mentioned "web content producer" because that's what my employer calls it. I'm not fond of the term really. I looked at that link and the User Persona for "Advanced Content Creator" is very much like what I do - landing pages, forms, views, light graphics creation, web pages with a variety of page layouts, some written content, video.

Calling all cats! We're herding!

heather's picture

Thanks to everyone on this thread who has helped shape and define the direction. Johan has done some great "cat herding in bike shed infested waters". Finally, he has posted the latest iteration out for public review to a wider group.

We've formed some specific questions we'd like to use to focus the conversation. Please share this with anyone you know who has been learning Drupal, and anyone who is teaching others Drupal... which I think accounts for pretty much anyone. (Since we're always learning something new).

Also, if you've been following along with the larger project, there's been an update to the roadmap.

Roadmap updated!

Itangalo's picture

Sorry for spamming this thread with comments – but I wanted to say that the road map is updated!

There are a number of "important next steps", and I think most of them should be carried out one way or another. There are also a number of suggestions as to where to go next, and I hope that we can do some kind of voting to see which of these are popular. Feel free to have a look already.

The chart could use a new

threading_signals's picture

The chart could use a new role or modify one of the name of the roles or just add skills to include services that a security consultant can provide. I didn't see anything like that up there.

Feedback round one summed up

Itangalo's picture

There is now a comment summarizing the feedback for round one!

I hope to discuss updates and changes either in this thread, or in a new one. What is best?

Map and descriptions updated!

Itangalo's picture

All right! The skill tree and the descriptions are now updated, and most comments from the feedback have been taken into account.

Some issues that still need attention:

  • Mobile is now a part of "mobile and web services". Someone with more knowledge about these topics is welcome to update or add suggestions for update.
  • The front-end engineering probably needs better descriptions, and likely also a split into two or more skill sets.
  • Basic site building and advanced site building are still very general. I actually think that these could be skill trees of their own, since they could (from my point of view) contain as much as the rest of the tree together. However, it might make sense to split them up into 2–3 skill sets each, or maybe just renaming them to something else.
  • There is still no easy way to update the chart. We need a better tool for that to happen.
  • There is still nothing indicating that the skill map is relevant mostly for new Drupalistas. (We should probably discuss that more before making that an official statement.)

The feedback from round one is summarized here:

About the colour categories

Itangalo's picture

To make it easier for people new to Drupal to interpret the map, I've added colour categories with some labels.

I think it is important to note that these categories should not be interpreted as fixed and with sharp lines. Nor do they describe boundaries corresponding to individual persons or roles when working with Drupal. They are just a way of answering the question "what the heck is in this map", and once you have started understanding that I think the colours should be ignored.

Front end engineering - done for us! :-)

batsonjay's picture

Ha! Well, as you wanted, here's a more complete description of a typical front end engineer. It's actually an advertisement for such a person, wanted by a Boston-area agency Boston / Providence area game developer (actually owned by former Red Sox pitcher Curt Shilling).


Frankly, it perfectly describes both a) what I think I was referring to in suggesting this role, and b) describes what at least 2 (maybe 3) people here at Acquia do.

I don't think it's a split role. I think the very nature of this role is that it requires a multidisciplinary person, who can do everything from do UX testing to javascript coding & more.

If you want to pull more of the description on the above link into this page, either do so, or let me know and I'll try to pull in a few select items.

Software architecture

Crell's picture

Another important skillset not listed is software design and architecture. That's not the same thing as systems architecture (which is architecting a site out of existing building blocks) or coding (which is actually writing $ a lot in a .module file). It's designing and planning how the pieces of code will fit together, not how the pieces of building blocks (Views, Fields, Flag, Domain Access, og) will fit together.

It's also a skill that Drupal has historically lacked, must to our loss. Highlighting it as distinct from coding or site architecture could help us to accept it as the distinct skill set that it is.


Itangalo's picture

I like this skill set.
(Right now trying to find a good place to add it, but not having much luck.)


batsonjay's picture

+1 to the architectural role.

Expanding "advanced Drupal coding"?

Itangalo's picture

The skill sets "basic site building" and "advanced site building" has a problem of being too general, and while it would make sense to split them into many different skill sets, it would make it impossible to overview the full list of skill sets. (Or, at any rate, they would risk dwarfing other skill sets in a way that is unproportional.)

I'm starting to think that the solution to this is to have separate skill trees for these skill sets – and referring to these from the "main" skill map.

Would it be a good idea to try the same thing for "advanced Drupal coding skills"? If so, it could/should contain important components of software design and architecture, as well as Drupal-specific topics like the node access system, DBTNG, the render system, writing framework modules, and more.

Makes sense?

I think "advanced site building / coding" is ..

batsonjay's picture

.. different from Architect.

I know lots of guys who can build amazing advanced Drupal sites. But an architect is different; he/she does some unique things:

  • An architect for a Drupal distribution has to think about how all modules might fit together, what the balance is for various use types, how to maintain something over the long term, etc;
  • An enterprise solution architect is likely to think well beyond "just" Drupal; they think about how a solution has to fit into a larger picture (e.g. other business systems - like - or other technology stacks - like jBoss. So they have a multi-disciplinary role.
  • A Drupal (solution) architect might be somebody like Chris Pliakas, Christian Yates (both at Acquia) who think widely about architect overall customer solutions, but don't actually implement it.

In all cases, though, they're really doing more than just doing advanced coding on a website. They need to think and work at a more abstract level, across either multiple tasks, or multiple contributors, or multiple technologies, and architect a solution that ties them all together.

I distinguish all of these from a "Drupal (core) architect", since that's something like what an Angie or Dries or Larry G or somebody like that is, and they earn this designation through accomplishment - not training. :-)

There may still be a need to identify a curriculum target for somebody who wants to be an advanced coder. I think the bulk of "really good Drupalists" are "advanced coders", and those who aren't yet one of them can go learn a lot in some training, and start to become an advanced coder. They demonstrate the ability to code just about anything in Drupal.


dgoutam's picture

I have not found QA( White-box testing and Black-box Testing) in the chart. I personally think QA skill could get a chance to be listed out here at this chart.

Integration skills?

valthebald's picture

Excellent job done!
My 5 cents - would be nice to add integration (with non-drupal systems) skills - especially for mobile. Like development for Android/iPhone, various connectors etc.

Great list

alltooeasy's picture

Great list, helping me to identify where to head next!
IMHO - Maybe site builder should have its own class, e.g. Drupal Gardens/Pre-Configs/Installation Profiles and eventually Features?

I suppose this is where some of the en-masse wordpress cross-over might have some potential.

Possible additional skill sets

Itangalo's picture

Here are some possible new skill sets I've come across

  • Quality assurance, as suggested by dgoutam in this thread. To some extent this is covered by continuous integration and automated testing, so we'll need some closer description of what kind of QA is intended.
  • Architect, as suggested by Crell and batsonjay in this thread. I really like the descriptions batsonjay gives, and I think they can be the base of more than one skill set.
  • Distribution/profile skills. I'm not sure this qualifies for a skill set of its own, but I personally think that distributions and profiles will play a major role in Drupal's future.

How do these sound to you?

Wouldn't there be several skills/roles for building distros?

gusaus's picture

Wouldn't there be several skills/roles for building and maintaining distribution and profiles? Seems like it would encompass many of the roles listed here.

Great to see this discussion moving forward again!

Gus Austin


fending's picture

You are correct, @gusaus -- "Maintaining a Distro" is a really wide skillset (part of why it's hard to sustain!) and Installation Profiles are similar in that many roles are involved. One of the under-appreciated and highly valued parts of this matrix is the "Configuration export" skill set, which overlaps with Features much of the time. I must say, I've been using a skill set matrix for a couple of years now for staffing projects / vetting hires and what's on this page is a superset of that. I'm really glad to checking back in on this, as well.

Wanna see!

Itangalo's picture

If there is anything in your skill set matrix not represented in this graph? If so, I'd be happy to see it and get new ideas.


I worry about over-segmentation here, and goals.

batsonjay's picture

While we could definitely have roles like "distro builder," I actually think we shouldn't. Here's why:

a) This discussion is all about what roles we want to have training for. I don't think there will ever be enough demand to have training for distro-building. It's not like we're going to have literally thousands of distros that we need to train large numbers of people for.
b) If this turns into a certification question, I don't think any certification from anybody is going to influence any company to hire somebody to build a distro. Any company that wants to build a distro and is hiring somebody to build it will likely base their decision on whether the individual is a fit for a company. They'll also do a pretty deep look at their Drupal skills independent of whether they've got any training/certification; the type of company that would be building a distro is going to be a Drupal shop anyway, and they'll likely know how to evaluate skills pretty well.

I also don't think there's any sense in splitting up the distro skill role description here. Yeah, there are different skills, but often a Distro isn't built by one person; there might be an anchor techie, but they're going to leverage others - e.g. themers, or whomever - to handle things they don't do themselves.

Different goals?

Itangalo's picture

I don't see this skill map as only what we want to have training for – for example, I also see it as a resource for knowing what skills may be relevant to learn as a Drupalist. Thus, a skill set can be meaningful (as I see it) even if there isn't economy in creating a course for it.

Maybe we should have some discussion about the goals of the skill set map – and also about the larger open curriculum project.


guru4vedi's picture

What about the "ability to identify a right Drupal Distro." as a solution?

Skill set suggestions

BJ___'s picture

For mobile skills can I suggest

-Understanding of mobile applications verse web apps, and how they relate to Drupal and what you can do with them. (Project management & Planning)
-Understanding of mobile development (Coding). Objective C, Java, Coca touch, Titanium, Web apps, Javascript
-Mobile application design (Design Skills specifically for mobile devices)
-Mobile user interaction
-Mobile application layout

For Drupal skill sets may I also suggest that a good knowledge of Database's SQL and other query languages can make or break a coder

Also I think along with Community skills I would also like to suggest
-General people skills (understanding what users/clients/managers/coders want is possibly the most valuable skill someone can have)
-And along the same line of thinking I think it's also important to "know about things other than Drupal" this provides the opportunity
for people to provide their specific experience to Drupal and improve it without being in too much of a bubble. For example "Wordpress does it this way and it's actually a good solution we can learn from...."
This might be a bit too general of a comment to be useful. Maybe "Experience with other content management systems" might be a good start but there is soooo many more skills that people have that are available.

Debugging and problem identification

z.stolar's picture

I propose to add debugging and problem solving to the list. This is done (and measured probably) in several levels:

  • Identifying visual bugs and their source
  • Places to look for alerts: error messages, watchdog, server logs
  • Using Devel module to inspect expected variables and strings output
  • Using a debugger in conjunction with a code editor

Debugging Drupal is one of the key skills to be efficient (and not suffer too much) when developing for Drupal. Knowing the common problems (i18n, permissions, js/css caching etc.) may save a frustrated developer a lot of time and money. Doing it efficiently is not obvious. A lot of it is experience, but some of this knowledge can be acquired rapidly, and it's definitely one of the aspects I'm looking for in a candidate.

Coding and theming in one?

Itangalo's picture

Great additions – it is actually difficult to believe that debugging hasn't been explicitly mentioned before.

I think these can be added in one of three different ways:

  1. As a new skill set, "debugging and problem identification"
  2. As two new skill sets "theme debugging" and "code debugging"
  3. As parts of existing skill sets

I'm not sure which of these are best. My instinct is that it is easier to view coding and theming separately – but that might be a part of my (stereotypical) division between themers and coders, which may or may not be valid. If "debugging and problem identification" is a skill set you want to learn as a whole, rather than aquiring parts of the skills and being happy with that, I think it should be one single skill set.

The same criteria could probably be used for determining if the skills should be a part of another set, or not. If "basic Drupal coding" is fine without knowing debugging, for example, then using Devel module probably shouldn't be a part of that set.

Here's a suggestion, just to have something to improve:

  • Identifying visual bugs and their source goes into "basic theming skills".
  • Places to look for alerts goes into "basic Drupal coding skills".
  • Using Devel module also goes into "basic Drupal coding skills".
  • Using a debugger in conjunction with a code editor goes into "advanced Drupal coding skills".

I am most hesitant about the last of these suggestions, so I hope that there are people that can improve it. :-)

Multi-level Drupal Setup skills

gurubydesign's picture

First of all, kudos to this group and this great discussion.

Having been hesitant to edit the Cacoo diagram for the Drupal skill sets without consulting you guys first, I'd like to suggest that we delineate skill sets for Setting up Drupal according to various levels, as suggested by idevit in his comment as a response to my post. Setting up Drupal in development boxes is one thing, but being forced at times to implement the CMS in existing enterprise infrastructures can be a pain in the ass. I believe that the skills required to do this should at least be mapped, so that developers who have experienced implementing Drupal in IIS/MSSQL or Oracle for instance could define the required set of skills and technical know-how. Eventually, this could help in accurately assessing developers' skills in setting up Drupal across various environments and help planners in staffing projects later on.


idevit's picture

The Skill set as currently in the Cacoo diagram focuses on Drupal specific tasks.
I believe that's a good strategy for now.

The mentioned 'Setting up Drupal servers' is targeted at *AMP stack on a single host this can be local development up to small VPS.
If we want to add (multiple) tracks for hosting and deployment specialization as mentioned above by gurubydesign it could be another subset (darker blue) with server architecture specialisations.

One important attribute we're still missing is the process of Professionalizing Drupal.
It could be a community skill emphasizing the process of:
- Marketing Durpal as a full fledged solution for business and enterprise.
- Addressing and proving solutions for the ever increasing demand for Support.
- Professionalizing clients. (Good clients know what they want or at least listen and pay handsomely)
- Increase community professionalism.

Professionalizing Drupal

linclark's picture

Professionalizing Drupal doesn't sound as much like a skill as it does an activity. How does one "level up" in professionalizing?

Goal as asset

idevit's picture

Fairly equivalent to "Community participation" and "Active community contribution", just a matter of filling up the skill set / expectations. There are several good examples i name one: the session at dc london by four kitchens

One of the key potentials of this skillmap group and the guilds group is is to create the backbone for professionalism within the community.

So its not only the bigger "Drupal Shops" who are taken seriously by the corporate world but also individuals or groups willing to professionalize.

Skills tracking file

SimonHoare's picture

To help people here, I have created a Drupal skills tracking file in Excel, based on the graphic at the top of this page and the accompanying terminology.

You can find it here on my site, underneath an introductory/explanatory text.

ODT available?

z.stolar's picture

Hi Simon, this is very nice. Do you think you can publish it also as odt (open office)?

.ods version

SimonHoare's picture

Ok, there is now a "compatibility" version in .ods format up on the site. It's mostly fine but has lost some of the colour formatting (i.e. gradient fills).

Could you test it please and make sure it works as you need.

.ods of course :)

z.stolar's picture

... and not .odt :)

Tested - it looks and behaves just fine! Thanks!

That's a good and very

SimonHoare's picture

That's a good and very appropriate idea ! Let me look into that.

git skills?

rachel_norfolk's picture

The Skill Set is currently specifying "git skills" and, while Drupal as a project does use git, I don't think it is the right way of expresssing what (I think) we mean here.

Maybe a better thing to say would be "Source code and configuration management" skills, of which git is currently a part? Being able to manage sourcecode is a lot more than knowing what the commands in git, or any other tool, provide. It's just as much about approach to source code management...

If people think I'm going somewhere useful with this, I'm happy to update the diagram.


When you click on the link of

dasjo's picture

When you click on the link of the images, you will end up on an outdated diagram version:

Are the newer versions available somewhere in higher quality?

Not that I know

Itangalo's picture

I was the one who made the image at the top of this page, and as far as I know there is no newer/better version available. :-/


ssankarsiva's picture

Essential skill set lists

So many great posts & related learning projects scattered about

gusaus's picture

Wouldn't it be great if we could gather up all the great learning materials and put it up in an LMS or something where everybody could access? A repository of free learning materials is probably something community members and orgs would buy into.

Gus Austin