On Mon, 26 Jul 1999, Chuck Mead wrote:
On Mon, 26 Jul 1999, Jared Buckley spewed into the bitstream:
Ok, since it seems like conversation on this topic has died down, let's
summarize and see if we can begin to move towards a consensus:
1) Do we need recertification?
Pros: It seems like the general sentiment was that recert was
necessary to keep the value of the certificate from going
stale and to protect LPI's reputation.
I don't think much of this argument.
Neither do I.
Cons: The potential exists for LPI to become a "paper mill"
generating endless recertification requirements as a source
of continuing revenue. (cash cow)
and this one is so bogus... it may be a legitimate thought but LPI isn't a "cash
accruing entity" beyond operational and developmental funding.
Yet if we do not have a good reason to require re-certification, that
may be what people will be suspecting and I would like to avoid such an
image.
% cut %
o Recert on "major" (-- undefined) revisions or at a
fixed time interval, whichever comes first.
Revisional recert is the way to go. Example: from RH5.0 thru 5.2 I wouldn't have
required a recert but for 6.0 I would and this applies to the issues outlined in
the next two points as well.
Note that this has to do with renewal of the exam content, which
really is a different issue from renewal of the certification.
Chuck's comment is only relevant for the distribution-specific part
of the second basic exam. We will allways lag behind the vendors, and
rather would like to have some control on when we will upgrade instead of
leave it to their marketing requirements. Maybe we can establish a
policy, like changing to a new exam whenever 20% (or whatever) of the test
objectives have changed. Such a policy can be used for the other exams as
well.
% cut %
b) After a major kernel revision release, i.e. 2.x.x to 3.x.x.
That is arbitrary: only a small fraction of the exams is influenced by
kernel issues. Again, this is about exam renewal which is different from
certification renewal.
c) Let the Employers/Employees (cert holders) Decide - In other
words, date each cert test passed and let potential employers
or the cert holder themselves decide if enough time has passed
that recertification is required.
All of these are really related to the same issue. Vendor releases containing
major changes will require a re-cert. They can take it when ever they want, in
my view (but I'd expect their employer is gonna dictate!).
Don't focus on the T2* exams too much. Nevertheless, we might offer the
brief distribution-specific T2* exams separately. Scott, will that be
feasible?
3) Do we make recertifying LPIC holders take the newest version of
the same test, or do we have special test just for recert'ing at
a particular level?
No special recert test... they should take the whole thing again!
I agree, for 2 reasons:
a) Not only do they show they know the new stuff, but they show they
didn't forget about the old stuff either.
b) It saves us the trouble of establishing and validating a whole range of
differential exams, which will probably cost more than it returns
(not only financially, but also in terms of resources and quality).
--
#!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@)
Tom "thriving on chaos" Peters
NL-1062 KD nr 149 tel.31-204080204
Amsterdam e-mail [EMAIL PROTECTED]
This message was sent by the linux-cert-program mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
