[lpi-discuss] Principles for creation of exam objectives

Torsten Scheck torsten.scheck at gmx.de
Fri Jul 29 03:33:43 EDT 2005

ross e. brunson wrote:
> 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
> 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.

I agree with both comments and I appreciate your thoughtful assessment
of each word of my statement. To be honest, I didn't pay so much
attention to my own words, as I tried to explain just the rough direction.

Now I realise, that both of you had already made the first steps in that
direction by that time. ;-)

I'm impressed by the work Ross' did with my 3 simple steps:

> 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 purpose of all my comments has been to get you (our stakeholders)
interested in our processes and invite you to check, if those processes
are okay in your books. As the former sendmail discussion didn't touch
those processes, I assumed that our processes are not well-known.

Here is the exam objectives review process for Level 1, which is in
progress right now:

I'm very curious which of Ross' points could complement our existing

Maybe there should be a new wiki page with Ross' work as outline, so we
can fill it with some more meat?

Thank you very much again for your contributions so far.


Torsten Scheck <torsten.scheck at gmx.de>  Jabber:torsten at i0i0.de
GnuPG 1024D/728E 6696 F43D D622 78F1  F481 45C0 2147 69AB DD54
software engineer:open standards/access/knowledge:enthgnusiast

More information about the lpi-discuss mailing list