Last updated by heykarthikwithu on Sat, 2015-12-05 09:01
Open Curriculum: Definitions – Scenarios – Roadmap – Skill sets – Open certification – References - 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 https://cacoo.com/diagrams/Fu6NuballS0GgW0d. 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 related skill sets
Skill set | Description | Comments |
---|---|---|
Basic drupal.org 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 drupal.org (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)
Current important tasks/questions
- We need more details descriptions of the skill sets!
- Are we missing any important skill sets?
- Some skill sets – in particular "web services and mobile" probably needs to be split up
Attachment | Size |
---|---|
Drupal subject areas (sketches).png | 36.57 KB |
skills-and-roles-top-down.png | 116.17 KB |
skill-tree-squared.png | 174.11 KB |
skill-tree-squared_4.png | 175.3 KB |
Comments
Great stuff here
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:
(btw, https://cacoo.com/diagrams/Fu6NuballS0GgW0d 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
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
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.)
Cheers!
//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?
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
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
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
http://groups.drupal.org/open-learning-and-collaboration-portal
Added tips from Bojhan Somers
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
Very cool! Thanks for pushing this along :)
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
Site building
Developing
Theming
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.
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.
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?
Updated
I agree that it does loose
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.
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:
OMG we need an
OMG we need an illustrator!!!
GREAT ideas!
We're up for it
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.
http://groups.drupal.org/node/173714
http://groups.drupal.org/node/167504
http://groups.drupal.org/node/136599
Let me know if we can help out.
Regards,
Nice graphics
Those images look really nice. Just saying.
Thanks
Thanks,
Let us know if there is something that eventually we could help with.
Excellent imagery. A while
Excellent imagery. A while back, others in the community attempted something similar to what you are doing. http://groups.drupal.org/node/67763. 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 http://groups.drupal.org/node/67763#comment-210478. 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.
thoughts?
I agree
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 /
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
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
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?
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
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
http://drupal.org/node/1245650
Back end: http://drupal.org/node/1245640
However I think employers would be a great place to start w verification.
Next step: Verify in the wild!
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
Amen. It is time to get outside verification that we're going the right way.
I'm gonna do the following:
I would be happy if you (yes, you!) could do the following
Rock on!
//Johan Falk
Heather is right. The last
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
Awesome awesome awesome. I'm working with heather to see where this overlaps http://groups.drupal.org/node/144584 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
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 http://groups.drupal.org/node/178434, with a Doodle poll for time at http://www.doodle.com/rppw8tigkhpebz5x.
Notes from the meeting
Notes from the meeting can be found here: http://groups.drupal.org/node/178434
The short-short version:
Front end engineering, and other roles
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:
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?
I think there are two other subject areas that might not be represented well here:
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.
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
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
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
-1-
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.)
-2-
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
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.
http://fourkitchens.com/blog/2011/08/24/mad-skillz-self-assessment-exper...
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...
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
Former Board Member Drupal Association (2012-2018)
@kattekrab
Yeah!
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
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".
Comments?
Simplifying chart creation :-)
"...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.
DI
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
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
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
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
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
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
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
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.
Volatile
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.
--
Kevin
http://www.webbfx.net/
Wow - I really like Web Content Producer
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?
(though it's a woman, and a different industry, does this sound like you)?
http://groups.drupal.org/node/183784
Advanced Content Creator
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.
http://www.webbfx.net/
Calling all cats! We're herding!
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.
http://groups.drupal.org/node/179414
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.
http://groups.drupal.org/node/172429
Roadmap updated!
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
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
There is now a comment summarizing the feedback for round one!
http://groups.drupal.org/node/179414#comment-603414
I hope to discuss updates and changes either in this thread, or in a new one. What is best?
Map and descriptions updated!
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:
The feedback from round one is summarized here: http://groups.drupal.org/node/179414#comment-603414
About the colour categories
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! :-)
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 agencyBoston / Providence area game developer (actually owned by former Red Sox pitcher Curt Shilling).See http://groups.drupal.org/node/182724
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
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.
+1
I like this skill set.
(Right now trying to find a good place to add it, but not having much luck.)
Yup
+1 to the architectural role.
Expanding "advanced Drupal coding"?
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 ..
.. 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:
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.
QA
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?
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
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.
http://www.alltooeasy.co.uk
Possible additional skill sets
Here are some possible new skill sets I've come across
How do these sound to you?
Wouldn't there be several skills/roles for building distros?
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
Yes.
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!
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.
Cheers!
I worry about over-segmentation here, and goals.
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?
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.
Agreed
What about the "ability to identify a right Drupal Distro." as a solution?
-guru
Harvest Technologies
Skill set suggestions
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
I propose to add debugging and problem solving to the list. This is done (and measured probably) in several levels:
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?
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:
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:
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
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.
Scope
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
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
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
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?
Hi Simon, this is very nice. Do you think you can publish it also as odt (open office)?
Thanks!
.ods version
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 :)
... and not .odt :)
Tested - it looks and behaves just fine! Thanks!
That's a good and very
That's a good and very appropriate idea ! Let me look into that.
git skills?
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.
Rachel
When you click on the link of
When you click on the link of the images, you will end up on an outdated diagram version:
https://cacoo.com/diagrams/Fu6NuballS0GgW0d
Are the newer versions available somewhere in higher quality?
Not that I know
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. :-/
Bookmarked
Essential skill set lists
So many great posts & related learning projects scattered about
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