In response to discussion by
"A.R. (Tom) Peters" and Alan & Susan Mead:
First: I appologize for anyone else who took part in the
discussion but was not mentioned. This was due to
a combination of not being quoted in the email,
and my recent start on the mailing list.
> If you reply, please delete some of the stuff we chewed
on sufficiently.
I'll do my best!
Note: anything stated here is not necessarily my opinion,
but a paraphrase of the above conversation.
Although, it can be inferred that it is difficult to
paraphrase without at least some opinion as to what
is important.
If you reply, it may be useful to keep the outline form.
This will enable points to be grouped with like points,
and keeps threads generally organized. From time to time,
it may also be necessary to strip the "> > >" from the
front of each line (provided this lasts that long).
Points made so far without regard to who made them:
--------------------------------------------------------
The issue that was originally raised:
What words and acronyms are so common that we may use them and
expect them to be known. (Ex. it would be silly to spell out
TCP/IP instead of using the acronym.)
I. We need to have a definitive list of them, with or
without explanation. This takes care that everybody
uses consistent terminology instead of any of the
possible synonyms
A. Candidates will be expected to know what is being
talked about when these terms are used, but do not
need to know exactly what the letters stand for
B. 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
C. Why would it would be bad to make explicit our
assumptions about terms that people should be familiar
with
1. The list will not mention terms (acronyms) that
don't really have synonyms
a. Ex. "Mail Transfer Agent" vs. "MTA"
i. Has a specific technical meaning
ii. Refers to a fairly well defined set of
programs in the Unix world
b. Synonyms of terms may be used when something else
is meant
2. Some terms may have different meaning in different
context
a. We should offer some definition or description
in cases where it may matter
b. Microsoft's tendancy toward bluring of concepts
D. Must specify in advance what jargon to use and what jargon
to avoid in the objectives and tests.
II. List two fields, the preferred term and alternate terms.
A. Would a definition be helpful enough to justify the trouble
1. Yes
a. The meaning of jargon tends to get confused
b. We need to have a definition or description of the
concepts and words we will be using
c. Just offering synomyms will not be enough
i. May not exist with acronyms
ii. May mean different things based on situation
2. No
a. No points were discussed
b. If you have points as to why not, put them here
B. Should it include a list defining which acronyms are OK to
use
1. Include what they stand for
2. Any other acronyms should be spelled out
C. Should be developed before each level of exams are written
1. Provide consistency across exams
a. Terms included on Level I Exams get carried to Level
2 Exams
b. New Terms from Level 2 Exams are added and carried to
Level 3 Exams
2. More workable than writing an exhaustive list right away.
III. We should avoid the use of jargon in the objectives and
tests where it can be avoided.
A. Offer guidelines on use of terminology to
1. Assure consistency
2. Avoid obscurity.
B. Don't bother candidates with unnecessary cultural trivia
1. Jargon
2. Abbrevs
3. TLA's
IV. The list So Far
Preferred Alternatives
--------- ------------
account: a login,
a screen name,
a passwd entry
CPU: Central Processing Unit,
box that holds the CPU,
box,
main unit,
processing unit
DNS: domain name server,
ip address resolution,
name resolution
network interface card: NIC,
Network adapter,
LAN adapter,
ethernet card,
ne2000 clone
________________________________________________________________________
This message was sent by the linux-cert-program mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
