Open Curriculum: Definitions – Scenarios – Roadmap – Skill sets – Open certification – References - Roles
Join the upcoming IRC meeting! Follow discussions here on g.d.o, on IRC at #drupal-skillmap, or on Twitter with the tag #drupalskillmap!
To help develop an open curriculum, the first stage is to lay a common ground for discussion. One step in the common ground is to identify some of the key roles in Drupal Development.
See the notes from the related discussion on 10 May 2010, Learning Drupal chat on IRC. Attendees: Ryan Price (DrupalEasy); Barry Madore (Advantage Labs); Richard Patee (Victoria School of Business and Technology); Emma Jane Hogbin, Author; Gus Austin (Open Learning); Doug Vann, Trainer; Lynn Bender (Drupal Austin User Group); Eric_sea.
List of roles
Note regarding context: we recognize on many projects a person might take on some or even all of these roles. We're using the redesign of Drupal.org as the context for the associated roles. It's a larger project, therefore with greater differentiation in the roles. Therefore, helping to guide the discussion.
Note regarding tasks: the descriptions in the roles mentioned here are not exhaustive. We're mainly focusing on the names of the roles. The descriptions are for clarification.
The next step is to undertake a more detailed task analysis, with the community. So no worries, we'll get to it. The first thing we need to do is ensure we're on the same page with roles.
* System Architect
This person sets up and maintains the system and infrastructure on which Drupal is deployed. They can manage the migration of data and content. They also install and maintain access to the site and version control. An example: http://groups.drupal.org/node/66638
* Developer
This person can code custom modules according to coding standards and best practices. They can test the quality and security of the code they write.
An example: http://groups.drupal.org/node/66643
* Themer, Front-end developer
This person can interpret visual designs into code. They are experienced with the complementary skills of HTML CSS and JavaScript. They can use theme functions and may be able to create custom modules to implement hooks to create displays they need.
* Site Builder
This person installs and configures modules to create site features. They will be knowledgeable about theming and development, but will mostly use Drupal through the administrative interface.
* Content Editor & Manager
This person manages content and users on a Drupal site. They may not know many of the advanced functionality of the Drupal Administrative interface.
* Design, UX
This person may not know HTML, CSS or JavaScript. They specialize in visual design but with an understanding of the capabilities of Drupal which help them create designs which can be understood and implemented with their team
* Project Manager/Planner
This person negotiates project plans with clients based on the understanding of the capabilities of Drupal. They understand best practices and can communicate client needs in the language of Drupal to the team.
* Drupal Marketer
This person is knowledgeable about Drupal's capabilities and applications and can communicate them to clients and other audiences in ways best suited and understood by the client or audience.
Comments
Depending on the size of the
Depending on the size of the project, a project manager might not be the one working directly with the client to define the requirements. What about someone called a Planner (something like that)?
So... are you recommending to
So... are you recommending to change the word from Project Manager to Planner? I think the description is on the money, just want to get the right name for it. Added slash Planner for now.
We're basing the use of PM as it is used in Drupal dev shops:
See for example: http://sf2010.drupal.org/conference/sessions/care-and-feeding-project-ma...
Mainly we're only writing elements of their job description as it pertains to their need for knowledge of Drupal. So we don't need to say everything they do.
The word Project Manager is a big term, and may be too broad for our purposes, as you say. What do you think Project Manager means?
No, just suggesting that not
No, just suggesting that not all project managers are web strategist or requirements people. I have known quite a few that simply manage and don't get into the details of what is required. Project manager could empass planning but what about those who will do the requirements, interviews, strategizing but won't do the budgets, schedules, and resource management?
Drupal Architecture
Excellent! I would add an Architect role.
In my post http://groups.drupal.org/node/42236#comment-151453 I tried to summarize the difference between a multi-instance site where you have dev/staging/production and a single instance site.
You need a very different approach when you want to move changes between dev and stage and content between production and stage than you do when building a single instance site with things like panels and manually created content types.
"architect" carries a lot of
"architect" carries a lot of meanings for folks I assume. What if we distinguished between Information Architect, Implementation Architect, System Architect, etc.
Thoughts?
You are right
I meant System Architect...this is where the "hard-core" experienced Instructional Designer shows up!
There is a lot of detailed information on Drupal but what I found missing is the big picture. Even for a simple flow diagram I had to go to external resources http://groups.drupal.org/node/42236#comment-149893
By the way to Cindy and
By the way to Cindy and Valeroid and anyone reading this, we worked this out on Monday night in a discussion about curriculum, and you're more than welcome to join us. It's 3pm EST, 8pm GMT in the irc #drupal-dojo
Thanks, valeriod! Yep, the list above is following on from the conversation you linked to. As you said "personas" is what we're aiming towards. This can help tutorial creators tag content to help a learner climb their way up that learning curve.
Maybe System Architect is a better name for the first role, thanks!
With 7 role I think there are too many, so not keen to add more unless it's absolutely certain.
Added the IRC chat to my
Added the IRC chat to my calendar for Monday, thanks.
This is a pretty spot-on list.
This might seem like a small work product, but identification of personas is critical. Nice work, all!
@heather - I don't think there are too many roles, per se. There's definitely an opportunity to progress, for example, from site builder to developer to system architect, each role requiring significant skill & knowledge building. I think your apparent goal of simplifying might be in tracks like that, but the learning and career progression are definitely there. Like I said: Nice!
@idcm - Somewhere in that example or a similar path is a branch to becoming a Drupal project manager. I get the assertion that project management can be "just" ;) resource and scope management. If that's the case, the PM does not need anything but a cursory understanding of Drupal and the development process. I recall not all of the panelists in the care&feeding drupalcon session that @heather mentioned were Drupallers to begin with, but all of them had a development or technical background that allowed them to get up to speed quickly. It would be good questionnaire material to see how they trained themselves up, which I don't recall being part of that panel discussion.
I will be in the next IRC session, as well. I really want to see a well-structured OC developed to help me in my two roles in the Drupal community:
@ fending thanks for
@ fending thanks for appreciating the work. it's fairly deliberate, plodding and tedious, but important.
I can't take credit for all this, it was collaborative, and now I shall start a list of names of meeting attendees in the wiki page above. Credit where due!
I'm going to draft up a survey of skills associated with roles, looking forward to some feedback and maybe some pilot testers of the survey. Glad that dev firms are looking to participate.
This is a very good list
This is a very good list indeed. But I like the idea of progression tracks @fending mentioned. There seems a natural progression in skills increase from Content Editor to System Architect. But from the curriculum/competency perspective project manager and UX specialist seem extraneous. They are definitely people who work on Drupal projects but they don't correlate to Drupal skill levels. For instance, a Drupal company may want to hire a project manager who has at least the skills of a Drupal site builder or a Drupal front-end developer who has UX skills but I don't see those two as distinct Drupal skill sets - more general webdesign roles that need to be filled on projects and matched up with Drupal skill sets.
The other question is whether the skills at one level exactly subsume the skills at another. I know there are a lot of System Architects who can keep a busy site running and optimised but probably couldn't name five different WYSIWYG modules or discuss their benefits. Something a site builder like myself deals with all the time. So perhaps, it would be worth taking this into account somehow in the detailed description which is the next stage.
I think it would also be worth considering levels within each role. I really like the ACTFL definitions of Low, Mid, High (if not the terms themselves) for their levels of language proficiency - for instance somebody who has the level of Novice-High in a language can function at the Intermediate-Low level at least half of the time. They take into account the fact that people with nominally the same skill sets are still proficient to a different degree. So for instance, someone who has built 10 completely different sites will be more proficient than someone who has built 20 simple identical sites even if they have the same check boxes next to their skills. And this is something that can be assessed.
One last thing that seems to be missing is a consideration of involvement with/knowledge of the Drupal community in the levels. Which I think has to be taken into account. I don't mean this in the "Open Source-hippie" sense but rather the more pedestrian familiarity with procedures for support, information sharing and judging the reliability of contributors. This involvement will vary in kind and quantity with the roles and perhaps should only be used to differentiate the levels of achievement within each role. I think including it might not serve just to help define the roles a bit more but also send a signal to learners and potential employers that an important part of the Drupal knowledge-base lies in the community rather than just in abstract skills.
It would be interesting to see how these roles match with the Drupal jobs being advertised. I've seen a few job ads lately that were describing a position for which the skills listed seemed really excessive. So I think might really help employers think better about who they really need for the job at hand.
Dominik Lukes
http://dominiklukes.net
@techczech
Heya Dominik, thanks v much
Heya Dominik, thanks v much for your feedback!
In terms of progression or levels within each role, I think we'll be able to identify that by working with the community.
For example, initially we have to survey a sample of Themers, and find out what it is they actually do on the job; and a sample of employers to see what they'd expect Themers to do on a job. After that... we can do the analysis with a larger sample to see the frequency which certain tasks are done. The analysis can also allow participants to rank tasks on importance. So we'll know then, what it is a Themer does most frequently and most importantly; we'll know other important but less frequent tasks, and so on. Do you think that could be used to determine levels? We also might not have to put them 'in order' at this stage.
So that's two samples: 1) To find out what a person in a particular role really does. 2) To analyse frequency and importance.
You're right, as you pointed out, the System Architect (name pending), the Designer and the Project Manager do not have a comprehensive knowledge of Drupal. They may not interact with Drupal even on a daily basis. But they do require some Drupal knowledge. I think during the meeting we thought there was sufficient differentiation between what these three individuals need to know.
So yeah, I have met Designers who work in dev shops who don't know the first thing about Drupal or the community, and couldn't View their way out of a paper bag. But that norm isn't necessarily a good thing.
Also, in terms of the hippie community aspect, you have a good point. I think the first survey of tasks could bear this out. We should find out what routes they use for problem solving, information sharing/gathering, and judging the quality of contributions. Of course, it will also be interesting to find out if they don't have routes or if their routes are failing them. Good idea!
Please do pop in to the next discussion if you can.
Sorry, I just reread what I
Sorry, I just reread what I wrote and it is not at all clear. What I meant about Designer and Project Manager is not that they do not need Drupal skills but rather that they do not define a distinct Drupal skill set. So while someone might call themselves a Drupal developer, a Drupal site builder, themer or even a Drupal system architect, I don't think people would talk about themselves as a Drupal project manager or Drupal designer. Rather you'd say: "I'm a project manager who also has the skill set of a Drupal site builder" or "I'm a web designer who's also a Drupal themer".
While I can imagine a course called 'Drupal for project managers or UX designers', I would imagine it would be very similar to a basic 'Drupal for site builders' course. Having recently heard pitches from a few Drupal shop project managers and designers, I'd say that for these people to be effective members of a Drupal dev team, they should have at least the knowledge of a novice Drupal site builder.
Dominik Lukes
http://dominiklukes.net
@techczech
Architects
The system architect is perfectly clear with the description.
Which role is responsible for planning information architecture? Designing navigation, search and classification schemes? These are cross cutting concerns that designers, developers, builders and managers can all take on. Should it be defined as a separate role? Or is there a separate place for describing the roles that are shared among different members of the team.
I'd like to +1 Dominik's idea/concern about the importance of expertise about the community and skill in moving around it. I know some folks in Drupal shops whose role at their companies is to baby-sit issues in queues, navigate around the community, and push bug fixes and new features up into core and contrib modules. They may fix the bugs themselves or develop the new features, but I think their work is really focused on the community, core and contrib. It's ongoing regardless of any specific web development project the rest of the team is working on, and it's not necessarily a seniority benefit like "The team does the money making projects while I get to work on core."
Absolutely. The soft skills
Absolutely.
The soft skills around developing in an open source community are important. And more markedly so as individuals become more deeply involved in development. It's interesting that other open source communities are dealing with this particular issue, in terms of how to transfer this skill. They are defining what those skills and abilities are, and finding ways to help people improve how they participate in the community.
I think it's worth looking into, and seeing how other communities are tackling this.
Interesting discussion here:
http://opensource.com/education/10/4/can-professors-teach-open-source
Thanks, Benjamin for chiming in. There's a chat on tonight if you'd like to join us.
proposal to strategically rethink the process
Even though roles have been proposed, I still see discussion on those roles and for good reason. The objective to find compentencies is appropriate but I think the process being used could use some tweaking if you want to ensure that you are not leaving tasks out of your analysis because of the perception of what these "jobs" do or don't do. You might find in the end that the process I propose below brings you full circle to the roles you have suggested in the first post of this thread but at least you will have evidence that these are the "jobs" in the Drupal world.
Proposal:
Although there is compelling evidence that a job task analysis (JTA) is a viable tool for defining the scope of what would later lead to learning objectives, the job task analysis isn't necessarily the best process to use when there isn't a way to define for sure what the job is. JTAs are typically used in industries and businesses where jobs are definable (e.g., air traffic controller - definitely a definable job). In the situations where a "job" task analysis is not appropriate, ISDs often focus on a systems task analysis. What tasks does the system require versus what you would call the job performing those tasks.
Consider dropping the "job" part of this discussion (temporarily) and focus on Drupal tasks and the skills required to perform Drupal tasks. You can think of it as a skill buffet. For example, a person who "cuts the code for a theme" and a person who "cuts the code for a module" both need to know PHP and Drupal APIs. They might use these differently when they first start out (themer using php to produce markup and coder to create functionality) but if you ask seasoned themers what they are putting in their template.php files, you will likely see a lot of what a module developer would do - at least that is what I am hearing from people I talk with. Code development is code development. The level of complexity changes depending on what you are "coding." So define what someone can do in Drupal (e.g., plan/design UX, build a theme, build a module, build an API, build interfaces, build ... whatever).
You can still use a survey if you want. Just ask what tasks they perform and the skills they use to perform them. It doesn't matter right now whether they call themselves a themer, architect, planner, developer, coder, builder, web strategist, project management, requirements analyst, etc. We don't have to agree as a global community that it is an architect or developer performing that task. Just ask people to pick the profession they are most familiar with and ask them to list the Drupal tasks they perform. Identify the skills need to perform that task. I would propose a brainstorm, just get everyones dump - don't critique as you go. Assess and organize once you have a list.
A task/skill-to-job matrix would illustrate where the same tasks are performed by different jobs. Such a matrix could be used to help employers to write job descriptions and call them what they want.
Once the Drupal task/skill (e.g., competencies) are identified, we can make suggestions like "if you want to be a themer, we suggest you need these skills" but that person who trains in the theming track might be called a desiger where they work. Remember, you can design graphics, code, layouts, etc. You can also wear multiple hats and be called something generic. For a long time, I was called a TRW Sr. Analyst. What the heck is that? It was what my boss defined it (on a day-by-day basis sometimes). I bet there are a lot of people out their working under one title but doing so much more.
By focusing on skills you need to do Drupal tasks (things we can definitely define), you let people define themselves. If you want to go in the direction of certification based on competencies, then define Drupal competencies (job competencies). Then group the competencies into "jobs" whose titles only matter in the certification world. Remember, not all Microsoft certified people have job titles that match the "MS role" that their certification defines.
I like this strategy quite a
I like this strategy quite a bit Cindy, especially since you recognize that in order to sell it to people, we will have to eventually re-collect the tasks back into jobs.
Ryan Price
DrupalEasy Podcast
@Cindy you're on the
@Cindy you're on the money...
Recognizing that in "real life" a person plays many parts of a few roles. However, it's interesting, the notion of roles seems to ring true with people. I was discussing "what you actually do" with some developers this past weekend at a DrupalCamp. It's not strange to hear someone say, "well I do mostly themeing, but I'm also sometimes a SysAdmin, and sometimes I have to do be a site builder".
Just as we know what a platonic triangle is, we don't see them in nature. I think the roles are a bit like that.
However, as a skills tree, I do believe the roles are going to be useful in framing skills and abilities development for learners.
I agree, we don't need a JTA. I thought we'd do it in a two stage process... first open ended to get a viable list of tasks and then the analysis w JTA to get an idea of the rating of tasks. However, I think the idea of a JTA is maybe outside the scope again. It's far too detailed for our purposes. We don't need to determine frequency and importance. I don't think the outcomes would be useful to either content creators, trainers or learners at this stage.
Role surveys
I do think surveying people in the community on what they really do is crucial. I am undertaking writing the surveys and piloting the surveys.
Sample two groups to find out what people in a certain role actually do.
- Ask people in the role what they actually do on the job, what it entails.
- Ask people who hire or manage people in the role to determine what they think people in the roles do.
Here is a draft of a survey
http://ietherpad.com/roleSurvey
Survey goals and objectives
I was looking at the etherpad and typed some chat comments and it froze on me. I guess it doesn't like IE. ahaha. Anyway, here are my thoughts in addition to what is in the chat window.
If we temporarily lean away for letting roles drive this effort and focus more on what Drupal requires from people who fill roles, we might be able to stream line this survey and focus it more on what is needed to define the tasks and skills associated with Drupal and how they map to "Drupal roles".
One of my chat comments was "it feels like we are trying to define roles before we define the drupal tasks that a role may or may not perform. i know that is how it got started but a person who does it all could end up filling out a lot of redundant questions based on the role they are imagining."
Regarding the manager questions, I am not sure that a manager who hires someone always understands what that person does in context with Drupal versus other tasks. Have you looked at the "skills" list that comes out with job ads for Drupal? Did you know that someone wanting a Drupal developer needed them to know PHP and CSS? On the surface, I would say that they were asking for a themer but then again, a module developer should know a little about CSS if their module needs any formatting. Did the manager actually understand this? And we all know there is a difference between programming in PHP and using PHP to develop in Drupal. So why don't the ads say they want skills developing for Drupal versus simply saying applicant should know PHP?
Has someone defined the objectives of the survey yet? Assuming the survey uses these draft questions, I am trying to determine what we will know at the end and how that maps back to our goal of defining the Drupal tasks and skills for various roles. For example, this is a good question "In relation to Drupal-based tasks, describe what tasks you are doing in your job everyday?" but since the survey is written to someone that is a themer, will that person be able to distinguish between their "theming" tasks and their "building" tasks or "module dev" tasks? Will they not share a task that we could find valuable because they are thinking about how they define being a themer? Then, we don't hear (from the person who does the task) what skills they use to execute the task. We ask the manager what skills they think they should have. So, if the survey taker is not a manager, we might not get the skills information.
If I am correct in understanding our goal is to solicite information about the tasks people perform in Drupal, the skills they use, and the role they associate with the task, then we might limit our questions right now to those that will get us the answers. Then, as instruction is designed and developed, we can investigate the resources they use and how often they perform certain tasks. A manager survey could look into how business label roles. The survey could be, of the tasks listed below, which do you associated with role X. From this we can identify role expectations and where there is misunderstanding or not.
As for which modules folks use, I would first look at Drupal stats to what is being used. Also, the tasks will point us in that direction as well. If nobody defines a Drupal task associated with let's say ... Domain Access, it might be that a competency in partitioning sites is not somehting we do right away. I don't know, just something that just came to mind.
Cool, after discussion - We
Cool, after discussion -
We will form a generic survey to ask Drupalistas (for lack of a better word) what they do.
The roles above form a hypothesis.
Still remains to be seen how we will survey those who hire or manage Drupalistas.
Now time to talk to people and pilot the survey. :)
Planners Guide - online resource
In an article comparing WordPress, Joomla, Drupal and Plone, Idealware said "The flexibility of the [Drupal] system means it's important to think through the best way to accomplish what you want before diving in."
I have been working on a book for planners to address this very notion. Drupal Websites: A Planner's Guide (http://planningdrupalsites.com) is being offered as an online resource to help you "think through" what you want and need before diving in with development decisions. I have decided to make it an online open source resource.
The first four chapters are online and ready for people to consider. There are 160 nodes covering topics thru the requirements phase. I will be finishing this over the summer (she says with confidence ;-). I h ave sent a message to Addison to see if she feels that a planners guide should be added to the DO guide list. There are guides for builders, themers, admins, developers, etc. Why not planners?
Once I have the core of the book done, I will open it to the community so others can post their planning tips and tricks. If there is anyone who wants to partner with me in the writing process, please let me know.
After you take look, tell me how this overlaps (or doesn't) with project management and system architects. "Planner" is just a simple, generic term I have found seems to ring true with folks.
looking good. skimmed it and looks useful already
The path section is important and I sometimes have difficulty to getting people to consider that part of planning.
The mapping of wireframes to drupal constructs is a major headache. I've been using the context module to bridge this gap by having the designers first define the names and conditions (path, user role, etc.) of a context. Then have them define the reactions (what blocks and themes go with with what contexts). Here's what the wiki looks like for a project with this approach: http://www.johnbarclay.com/Contexts_x_Content.pdf
Also, you might install the glossary module in your book. It will automatically add links to any taxonomy terms in your site. You just define all your terms in a taxonomy and it takes care of the links.
www.johnbarclay.com
Thanks johnbarclay. Would you
Thanks johnbarclay. Would you be interested in turning your map into a tool? Maybe include some helpful tips on what to put in each column? I could link to it from my site so folks have options on how to organize themselves.
Ah, yes glossary. Forgot about that. thanks :)
Will document it next time I use that approach on a project...
and let you know where to link to it.
www.johnbarclay.com
Added two roles
I just added two new roles to this list – the marketing person and the community member. I think both of these are valid when it comes to Drupal competencies.
The marketing person plays a limited role in individual Drupal projects, but is important both for Drupal companies and the large Drupal project. Thus, describing required marketing skills makes sense.
The community member role is a way to describe the skills needed or built up as an active member of the Drupal community. Being a part of the community is a way of knowing what's going on and how Drupal evolves both as code and as phenomenon. Good community member competencies may be useful in individual Drupal project – especially those running over a long time – but the main use is probably to describe skills that are useful for the community.
I think it make "community member" its own role, since it involves skills that otherwise would be attached to all the roles.
//Johan Falk
**
Check out NodeOne's Drupal Learning Library! 190+ screencasts and exercises, for Drupal introduction, advanced configuration, and coding. Creative Commons license!
Advanced content creator
Adding a link here, to batsonjay's "User persona for advanced content creator".
Using Personality Survey to Good Career Roles
I really like this node because I have been looking for a role list, and have been working on creating a personality survey tool to guide people new to Drupal into roles that best match their natural traits. I have a good test that thousands of people have taken over the last decade; I just need to automate it so I can collect data from many established 'Pros' to see if there is indeed correlation. I have been experimenting on my fellow students, and it is clear that some have influencing/sales skills that would make them good at getting customers and business; some are 'dominant' natural leaders that a big project would need; others are conscientious and very detail-oriented (probably good coders) and some are very steady (Phlegmatic) who are diplomatic, likable, practical who can teach and work well with others.
Here is the manual test:
https://docs.google.com/file/d/0B0YefhLd8JzrVmMycTdvLWJEeTg/edit
Here is a semi-automated spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AkYefhLd8JzrdGI2Yk1SVFlLWWs...
If anyone is willing to take the test and return data, I simply need their D I S C totals and the role(s) that best define their work.
James
jamesthequack
Roles/responsibilities to manage & sustain a Drupal product
Totally forgot about this list of roles. Assuming this is a bit buried and outdated, I'm wondering how the roles may have evolved over the years. Personally I'd like to know more about the roles/responsibilities and time requirements to manage and sustain a Drupal distribution or ongoing project. As each project is unique, there are many opportunities to create open curriculum from working on real projects in the open (for example).
Gus Austin