Boy, I respond to every paragraph you wrote. I could not cut back; if you
reply, please delete some of the stuff we chewed on sufficiently.
On Mon, 28 Jun 1999, Alan & Susan Mead wrote:
> From: A.R. (Tom) Peters <[EMAIL PROTECTED]>
> > I think this does not solve the issue that was originally raised: what
> >words and acronyms are so common that we may use them and expect them to
> >be known. I still think we need to have a definitive list of them, with
> >or without explanation.
>
> I think this is not a good idea (at least not for controlling test quality)
> because a list too long and filed with too many no-brainer terms will not be
> read.
>
> But we can do it your way, more inclusive is easier.
Please, it has not to be done "my way"; you are as close to exam
development as I am. It is just that I don't understand why it would be
bad to make explicit our assumptions about terms that people should be
familiar with.
It seems we all agreed that it would be silly to spell out TCP/IP
instead of using the acronym, and that we don't ask candidates what
exactly the letters stand for: we just expect them to know what we talk
about when we use "TCP/IP" in the objectives or exams. But we have to
draw the line somewhere, and we better be explicit where that is.
Your proposal - as I understand it - takes care that everybody uses
consistent terminology instead of any of the possible synonyms. That
leaves 2 problems un-addressed:
* The list will not mention terms (acronyms) that don't really
have synonyms: for example, you either use "Mail Transfer Agent" or
"MTA". If someone wants to mention that concept, it has a specific
technical meaning and refers to a fairly well defined set of programs in
the Unix world (sendmail, smail, qmail, exim, ...). I don't think many
people will try to find a synonym for that, and if they do, they probably
really mean something else.
* Some terms may have different meaning in different context: I think we
should offer some definition or description in cases where it may matter.
The list like you propose does not do that. Think of the peculiar meaning
established terms ("directory services" from Novell, "multi-user" from the
non-PC world) get in the Microsoft world, or the blurring of concepts
(e.g.: MTA, MDA and MUA are not clearly separated in an MS-Windows
environment).
> >> As I described in my previous message, I would just list two fields, the
> >> preferred term and alternate terms. Would a definition be helpful
> (helpful
> >> enough to justify the trouble)?
> >
> > Yes. Like Michael jang pointed out, the meaning of jargon tends to get
> >confused, especially between MS and Unix. So in some cases we need to
> >have a definition or at least a description of the concepts and words we
> >will be using. Just offering synomyms (which may not exist for things
> >with an acronym) will not be enough.
>
> So, here's my example again. What's wrong with, say, the DNS entry? Please
> be explicit otherwise the finished product won't be what you have in mind.
>
> Preferred : Alternatives
> account: a login, a screen name, a passwd entry
> CPU unit: [box that holds the] CPU, box, main unit, processing unit
> DNS: domain name server, ip address resolution, name resolution
> network interface card : NIC, LAN adapter, ethernet card, ne2000 clone
It seems workable, but it has this implicit: apparently it is OK
to use the acronym "DNS" (it is even the preferred term); whereas "NIC"
should be spelled out "Network Interface Card". I thought of a list
saying "These acronyms are OK to use (this is what they stand for...);
other acronyms should be spelled out."
> > This seems like a good idea, so please go ahead. But mind that the
> >stated goal was, to avoid jargon and abbreviations as much as reasonably
> >possible. It is not clear to me if you think we should not bother to
> >follow such a policy.
>
> You mean do I agree with your concensus point? Sure! (Who has disagreed?)
>
> Or if you mean, Do I know what to write (besides the exact wording of the
> point) in the item writing guidelines? No.
What I mean is: we should avoid the use of jargon in the objectives and
tests where it can be avoided (and have a list of terms that are OK to use
otherwise). I got the impression that you just wanted to collect whatever
jargon and TLA's were being used in the objectives and tests, and document
that afterwards. My concern is to specify in advance what to use and what
to avoid in the objectives and tests.
And BTW, I was hoping you were drafting some guidelines for item
writers?
> For example, do item writers have to spell out Transmision Control
> Protocol/Internet Protocol instead of TCP/IP (no, we already decided not, it
> would be dumb because TCP/IP is universally known while I had to look up its
> meaning just now). So do item writers have to spell out Domain Name
> Service? I'm guessing NO. So do they have to write out Network Interface
> Card (i.e., vs. NIC)? I'm guessing yes.
This exactly is the issue: where to draw the line, and it seems we
agree. It just has not become clear to me how your proposal deals with
this.
> The "I'm guessing" part is a little disquieting to me. If we leave it up to
> the item writers, then we have abandoned quality control.
>
> But I agree completely that this is a Linux test, not a acronym/jargon test.
Right, so we agree that:
- we need to offer guidelines on use of terminology to assure consistency
and avoid obscurity.
- we don't want to bother candidates with unnecessary cultural trivia
(jargon, abbrevs, TLA's).
> >> This would provide consistency across exams because any terms that we
> >> include on Exam 1 get carried to Exam 2. New stuff for Exam 2 (if any)
> is
> >> added and carried to Exam 3. And so forth. It also seems more workable
> >> than writing an exhaustive list right away.
> >
> > Note that the first level has 2 exams, which will be developed shortly
> >after one another. The second exam contains a distribution-specific part,
> >which is still under development.
>
> Yes.... But I'm not sure I take your point?
I thought you were confusing levels and exams. Exams 1 and 2 are being
developed almost concurrently (the objectives are all but finished), so
there is no transfer from Exam 1 (after it is finished) to Exam 2 (at the
time we started working on that).
There will be a transfer and extension like you describe from the exams
of Level I, to those of Level II: these more advanced exams will have more
jargon and acronyms anyway.
--
#>!$!%(@^%#%*(&(#@#*$^@^$##*#@&(%)@**$!(&!^(#((#&%!)%*@)(&$($$%(@#)&*!^$)^@*^@)
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]
