Learning Drupal - roles discussion (week 3)

Log for this chat:
http://www.disobey.com/bot/log/drupal-dojo/2010-05-17

Discussion summary:

• The roles are a hypothesis which we can test by piloting
• Here is a draft of the survey, questions welcome http://ietherpad.com/roleSurvey

We will look at the initial feedback next week.

Over the next week we can think about the objectives for this open working group:
http://groups.drupal.org/node/69413

Also some news about the group: you can tag training events and materials and we'll add a new tab!

The length of the course shouldn't have anything to do with your instructional strategy (role versus case based). Instruction is based on objectives, what does the learner need to be able to "do" at the end of the learning experience. Depending on what they need to be able to do and how you are deliverying the instruction, your strategy is then defined. Compromises are often made but we always strive to choose the best strategy.

If I may, I assume you all have heard of Bloom's Taxonomy (http://www.officeport.com/edu/blooms.htm). This is one way ISDers scope the "intensity" of the instruction. It is a list of verbs that defines the "do."

Please consider the following project process. It doesn't put a role debate at the start of the process thus increasing the probability that effort could move forward more quickly and would allow people to chime in more easily. If people don't agree that a task is performed by a role, it will be hard for them to get past that issue and progress will slow.

1. 1. List the Drupal tasks at a topic level
2. 2. Create a list of tasks using the verbs in Bloom's list (or use a verb that is not in the list)
3. 3. Identify which tasks are "prerequisites" of the other tasks (much like defining dependencies in module development, project management, etc.)
4. 4. Identify what skills are needed to perform the task, in addition to the prerequisites (e.g., experience coding database driven PHP sites).
5. 5. From a list of roles, how many of the tasks will that role need to satisfy. Remember that the Senior site developer will probably be responsible for each task and a project manager might only need to simply be able to list the tasks.

When you define your instruction, you state your terminal objective(s) and then identify the task topics that will be needed to meet that objective(s). The verb in the objective will drive how far you go in the list of tasks associated with the topic.

With this information available to the training development community, instructional designers can create training packages using a modular approach similar to the way people build Drupal sites. Tasks can be organized by a role that a company has defined or they can be organized by a product life-cycle (need, reqmt, design, develop, implement, maintain, sustain, retire/upgrade) or some other way they see fit.

With a module resource set (items 1-4 above), the community can naturally start drawing the lines between roles. The debate has been going on for years regarding who does what. An instructional planning process might not have the influence to bring those arguments to ground. BUT an instructional planning process CAN use what is given - Drupal tasks.

In order to complete step 1, you can use a survey coupled with the committee's own expertise to state the obvious tasks performed in Drupal. With this module approach, we could add tasks to the instructional package to include significant contributed modules - like facebook for drupal, domain access, services, etc. With this module approach, instruction based on cases would be more feasible.

My last argument for this approach is to support and/or utilize Drupal documentation development. Instruction provides the glue-ware that brings these tasks (and documentation) together and puts them into context and practice.

http://webchat.freenode.net/
Enter the name of the channel #drupal-dojo