Proposed Specs for Competency System

there are two parts: Competency repository and the competency-to-product mapping module

Competency Repository

The repository is a space/site dedicated to storing community defined Drupal-related competencies. But what is a competency? How are competencies organized? I have been doing some pondering and tested my thoughts with a google search.

Definitions: According to http://managementhelp.org/staffing/specify/cmptncys/cmptncys.htm, "Job descriptions typically list the tasks or functions and responsibilities for a role, whereas competencies list the abilities needed to conduct those tasks or functions. Consequently, competencies are often used as a basis for training by converting competencies to learning objectives." By definition "A competence is the ability to perform a specific task, action or function successfully."

General Requirement: These search results provide a way to hone what we already have started in such a way that I think many will be able to relate. So for our repository, I propose we need a way to capture 'ability statements' that can be mapped to tasks and their associated processes with the site life-cycle.

Examples: We have this started in our spreadsheet. For instance, the ability to 'Create a new content type.' The task might be 'content type development' and this task is probably associated with the 'build/development process'. Another example might be the ability to 'Create a node.' The task could be 'content development' and the process 'content management'. Another example might be the ability to 'Use the hook_form_alter API to change a form.' The task might be module development and the process might me the build/development process (like the example above).

Model?: We might want to look at how D7 organizes default tasks in Drupal to see if that task organization is a good model. It would certainly help sync up this effort with Drupal going forward.

Requirement Specs: Assuming all are in agreement with my assumptions above, I propose the repository have and do the following.

Competency field - long enough for a sentence (255 chars? or more?). Has a child relationship with the task field. Can have more than one task parent. Needs to be only one sentence/statement with an action verb (e.g., create, define, install, configure, etc).

Task field - should be a shorter statement (255 chars or less). Has a parent relationship with the competency field. Can have multiple children. Ability to have more than one process parent is TBD. Has a child relationship with the process field. The task statement should also include an action verb as tasks are actions. Tasks are broad enough to include multiple competencies but fit well into one of the core processes found in the site life-cycle.

Process field - should be a shorter statement (255 chars or less). Has a parent relationship with the task field. Can have more than one task child. Processes are high level and often represent a phase in a site life-cycle or a major effort within a phase.

Phase field (?optional?) - this might be overkill but it would simply represent work performed pre-launch versus post-launch.

Outbound 'feed' - the repository should allow other sites to pull a copy of the competencies, tasks, and processes into their site. The result of the pull should process something (terms, nodes, whatever), that can be mapped to learning experience nodes in their site. The learning experience nodes can be a registration form, a product description page, a video, whatever.

Inbound 'feed' - the repository could also allow sites to register their competency map/feeds (something part of the module they put on their site). From the repository site, people could look up a competency and see who has registered their learning experience product with that competency.

Competency Mapping Module

My thoughts on the competency-to-product mapping process. This is the module sites install so that their visitors can see which learning experience product meets the competency.

Requirement Specs: Again, assuming all the repository makes sense, the "user" side of this project would need the following.

Competency map field - a field that is pre-populated with the competencies from the repository. The field could be assigned to any content type. D6 version would require CCK. A D7 version would obviously work differently.

Views integration - the competencies, tasks, process, and phases(?) and their relationships(?) would be available to views so users could present their learning experienced grouped by competency in a block or page.

Inbound feed - pre-defined admin option that allows users of the module to sync their copy of the competency repository with the actual repository.

Outbound feed - pre-defined view feed that pushes the learning experience node(?) info, URL, and competency back to the learning experience list in the repository.

Implementation

I could easily see this as an architecture:

• A taxonomy vocabulary for the the competencies
• A content type for the competencies
• Taxonomy manager for maintianing the taxonomy
• Taxonomy xml for importing/exporting terms
• Other common drupal vocabs for tagging purposes

On the issue of merging the vocabulary with existing versions of the vocab on other sites, I think a patch to taxonomy xml that allows it to merge with existing vocabs would take care of the issue.