[lpi-discuss] Principles for creation of exam objectives

[ross e. brunson]

On Tue, 2005-07-26 at 16:43 +0200, Anselm Lingnau wrote:
> Torsten Scheck wrote:
> 
> > >>Let's convince the Linux-related industry, that LPI's exam objectives
> > >>define exactly the knowledge and skills, which are needed to get the
> > >>leading in-house Linux compentency.
> 
> What I don't buy here is the word »exactly«. Trying to get people to believe 
> that, you might as well try to convince them that the sky is green. I think 
> the best that we can hope for is a general perception that the LPIC exams 
> cover material the knowledge of which is highly desirable in a competent 
> Linux person. 

I couldn't agree more, getting our bunch of talented, bright and quirky
co-LPI'ers to agree on something will require us to feel we are being
heard, and if a compromise must be made, that it's one that must be made
for the good of the cert and it's viability.

> (As an aside, in my classes I try to get across the »Unix mindset«, i.e., 
> build bigger stuff from basic blocks, build stuff on top of existing stuff, 
> etc. Arguably, once you have grokked that it doesn't much matter what else 
> you know since it is all in the man pages, anyway. However, most participants 
> find it very difficult to get used to the idea of *building* anything at all 
> -- they seem to have been brainwashed into believing that if you can't click 
> on it, it doesn't exist, and to make it exist on your system you have to be 
> either some kind of Dark wizard or else spend $$$ to buy extra third-party 
> stuff. Unfortunately, it is very difficult to multiple-choice test people for 
> »Unixmindedness«)

See my dot pitch rant below.  Whenever I explain something, or want them
to see how it work, I use the console and projector to build it step by
step with them, have them use markers that join together to visualize it
etc.  Remember to use all three input/learning approaches, visual/audio/
kinesthetic, they'll get it much faster.  I also have them try commands
and do mini labs on things that I just showed them about 50 times a day,
it really helps.  They all know to start typing when they hear "Try this
now!"

> > I just presented three simple steps regarding our exam objectives:
> > * define clear principles for exam objectives
> > * review exam objectives according to those principles
> > * promote exam objectives
> 
> Right. This reminds me of the traditional method of how to carve an elephant 
> from wood: Start with a big hunk of wood and cut away everything that doesn't 
> look like an elephant. Simple.

Exactly, like when a new cool piece of software that purports to make
Linux easier for Desktop users begins with a "simple" recompile of the
Kernel or a 12 step process for loading SSL modules so you can then
install the damn thing.  I'm a techie and I expect to go through some
hell to get what I want, but not my users.

I have developed over the years what I call "dot pitch" which means that
almost anyone can understand anything you care to teach them if you
connect enough dots (technical points) properly.  We've all stood there
trying to connect dots for various people, but they need a greater
density of dots, or explanation points.  The ability to recognize this
and drop to a more dense dot pitch, as it were is essential for getting
an idea across.

I would submit that the list above has a dot pitch so high as to be
almost useless (Sorry Torsten, not picking on you.)  Here's a quick
layout I jotted down after reading the original list:

Define clear objectives for exam objectives through:
  -  Polling sysadmins as to most commonly-used packages
  -  Normalizing between "real-world" and "included-with-distro"
packages
  -  Publish the methodology for polling and normalizing the feedback
  -  Elicit buy-in from the community in a formal and organized manner

Review Exam Objectives according the above principles
  -  Poll to identify most problematic objectives
  -  Prioritize the feedback and normalize with common sense
  -  Elicit updates to the problematic objectives
  -  Revise the current objectives to reflect the mix of reality and
possibility noted above

Promote Exam Objectives
  -  Publish proposed Exam Objective updates
  -  Set a public comment period and enforce it
  -  Resolve the comments with to the proposed objectives
  -  Republish the revised objectives and elicit any new commentary
  -  Put the finalized objectives through the Psycho-Metric process

The reason I put what I put in the Promote Exam Objectives section is
that I feel buy-in from the community is ESSENTIAL to proper promotion
of the objectives for any community-driven exam.  Not listening to every
nut-case and whackjob that wants to have us all using some weird
package, but enabling the majority of us saying "yep, that's a fair
thing to test on, and it's not so specific that I can't stand behind the
objective, though I use package X instead."

The real thing is that if you notice the problem, it's partially your
responsibility to help fix the darn thing, or at least make a good
attempt at getting it back on track.

Ross

> Anselm
> 
> (This is my personal opinion and not that of Linup Front GmbH.)