RFD: misc.jobs reorganization
Eugene N. Miya
=======
The following starts an official restructuring of the misc.jobs.* hierarchy.
The reorganization will be done in two-parts:
Phase I:
Status of misc.jobs.offered.entry
Straw poll prioritizing the rest of misc.jobs.* [m.j.*]
Geographic split
Recruiter split
Hierarchy by job description starting with a computer/non-computer split
Robomoderation
Phase II:
Discussion and voting on the more general misc.jobs.* reorg and subdivision.
Abbrev.
=======
RFD == Request for discussion (aka CFD) "official terminology"
CFV == Call for votes
m.j.o. == misc.jobs.offered
m.j.m. == misc.jobs.misc
m.j.o.e. == misc.jobs.offered.entry
m.j.r. == misc.jobs.resumes
m.j.c. == misc.jobs.contract
Other Examples used:
ba.jobs.* -- Bay Area [San Francisco] local job news group
ne.jobs.* -- New England [USA] local job news group
YMMV == Your Mileage May Vary [another term for generalization]
etc.
Introduction
============
The misc.jobs.* readership is one of the most transitory on the net.
[ one reviewer disagreed 8^):
Hah! I'd say that because it is transitory, people are ill-behaved.
They don't read it for a year or two, they read it for a week or a month
and don't bother reading it at all before posting.
But we carry on.....]
It is generally one of the best behaved news groups, because m.j.* directly
affects people's lives. So any reorganization is very important.
A reorganization must follow general Usenet guidelines on the
total vote count, the difference of >100 votes to pass things, etc.
As one of the keepers of the m.j.* list of FAQs, I have decided to take the
issue by the horns. I have consulted with other m.j.* FAQ holders and
contributers, and we have come to some agreement on the following two-phased
reorganization.
Phase I: Misc.jobs.offered.entry
================================
Misc.jobs.offered.entry:
M.j.o.e. was created under the auspice of a six-month test-period as was
pointed out by several m.j.m posters. Since none of them has taken
the group by the horns, I'll start with this. The group proposers have since
left. The transitory reader/postership has not really grasped how the net
works (they have not been networking very long): they have not read nor
comprehended the group name, can't edit headers, and they are unaware of FAQs.
The idea behind the group was to separate posts to help entry-level
readers find jobs. This has to some eyes, not succeeded. It has several
different FAQ issues which I won't explore further. The perceived problems
are:
Not enough entry-level positions:
This was foreshadowed by those who pointed out that creating a group
doesn't necessarily create the traffic to go there.
Noise:
people following up posting commentary, not redirecting it to m.j.m.
This is a problem with m.j.o as well.
Blacklisting/White listing:
the postership is mixed with jobs inappropriate for readership
(too much experience required) or follow ups.
Many jobs posted here are not legitimately "entry level".
Moderation:
Nobody has volunteered.
Employers who post job offers aren't bothering to read the different
descriptions of the different group, and just post to misc.jobs.offered,
(and worse yet, misc.jobs.misc) even if it would be more appropriate in
m.j.o.e. (Note that this is an argument against further split of m.j.o.
as discussed later in this RFD.)
Would renaming the group help?
--No.
The question at hand in Phase I is:
Should we remove misc.jobs.offered.entry?
Yes No
This will not be a straw poll question. This will be an official vote.
Personally: I have no qualms either way. You can remove it or keep it.
It is my position that any poster dumb enough to do the wrong things
needs to accept the consequences of their post. They have to take
responsibility. If that means unemployment, so be it. We can inform
them of their mistakes, but if they continue to use the net in
inappropriate ways, that's their consequence. I regard these groups as
intelligence tests to the people I want to hire or recommend against.
I won't take a resume from someone who posts to m.j.o*, period or look
at an offering cross posted to m.j.misc/resumes. So I claim no bias.
["I blame society." "Rrrright, we'll arrest 'im, too." -- Monty Python]
Well, I do have a tiny bit: if the group continues, I will discontinue
crossposting all FAQs there (as Snoopy did from the start, because I
get a heavy amount of email to "do something," and this is the last
"something).
Phase I: The straw poll
========================
Now the following is not a vote; it is an enumeration of issues which
need to appear on a straw poll for reorganization in phase II.
The purpose of the poll is to prioritize the readership's requirements.
^^^^^^^^^^
My plan is to summarize weekly; my take on the discussion of this topic
should should see three summaries and then the final ballot on the CFV.
Your discussion needs to address these. Easy stuff moving to hard stuff:
Misc.jobs.resumes
-----------------
Misc.jobs.resumes: unchanged as proposed.
A computer vs. non-computer split has been proposed in m.j.m. at one time.
Misc.jobs.contract
-------------------
Misc.jobs.contract: unchanged as proposed.
Misc.jobs.misc
--------------
Should misc.jobs.misc be renamed (Snoop's position)?
Suggested renamings are:
No change.
misc.jobs.d # traditional Usenet/MIT LISP-ish way
misc.jobs.discuss # Linda Richman's SNL method
misc.jobs.discussion # English teacher/student proposal*
No moderation in any form is proposed for this group (See robomoderation).
(*actually, they would spell miscellaneous out).
[I vote no renaming. --Stern:]
M.j.m is the discussion group for various job related issues not merely
to discuss the m.j.* hierarchy:
salaries, vacation policies, should I lie on my resume,
how do I ask for a reference, what do I do about my stupid boss.
{Yea, but this is the discussion not the vote.--enm}
This is the gist (the crux 8^):
Misc.jobs.offered
-----------------
You must think long and hard about the following issues, because once the
vote is taken, if it is defeated, it will be six months before a new CFV
could be started. A large portion of the problem is lack of readership
knowledge. It is assumed that a knowledgeable reader uses all the tools
available to him/her.
Misc.jobs.offered no change, or
Misc.jobs.offered removed and replaced with a hierarchical base of one or more
of the following dimensions (note we face what the programming language
people call "the orthogonality problem" for each dimension, we have that many
subdimensions we will have to face; so consider your choices wisely):
Recruiter split
Geographic split
Hierarchy by job description starting with a computer/non-computer split
Robomoderation
These and other dimensions raised by the readership of m.j.* require
prioritization.
Recruiters
-----
I've nothing against recruiters, and I don't appreciate the problem.
You have to convince me of the problem and suggest what to do and how it should
relate to the other dimensions of reorganization.
Note: simply having this group name does not restrict outside cross posts.
If an obnoxious recruiter exists, see the comment about Killfiles below.
Use of keywords in Subject lines: This we have tested this extensively.
It's unenforceable without moderation, and we have not reached consensus on
their use. Moderation is time consuming.
With one possible exception (See Robomoderation).
Geographic:
-----
Geographic splits can be difficult. Many local groups exist already
(ba.jobs.*, ne.jobs.*, etc.) and more will be formed.
The idea that a local group can restrict readership is flawed (like
US isolationism): the net doesn't work that way. The news group is
international and not merely national (divisions mentioning just the 50 states
will be ignored). Technical problems also exist regarding the structure of
news networks and how multinational companies gateway news throughout
geographically distributed sites (why people in H-P England can read about
goes on in Silicon Valley).
The objective here is supposed to be restriction by the Distribution: field
of the header. The problem is that the network "leaks."
This approach will easily explode into a huge hierarchy that only meets
the needs of a portion of the job seekers (those who are willing to
relocate must subscribe to the majority of the hierarchy).
Thus, if I wanted to relocate to Florida, I'd subscribe to
misc.jobs.offered.usa.fl. For all I know, they'd probably want to
subdivide further by county, then city, then street address. =^) <- Steve 8^)
Hierarchy by job description starting with a computer/non-computer split:
-----
We have looked at how newspapers do this. It's messy anyway you look at it.
[We needn't emulate the current newspaper scheme, and are free to implement
our own. -Steve]
[Note: you have the same issue as with m.j.o.e: the non-computer
job companies are less likely to be reading/using Usenet. If you build it,
they won't necessarily come. A new misc.jobs.offered.medicine, for example,
might be mostly empty -- better to read sci.med and look there.
(In fact, as a real example, sci.geo.meteorology often contains position
availability announcements.) -- Stern]
News readership issues
-----
Specifically on the issue of anyone reading news:
A knowledgeable reader must be assumed to know how to use tools like
kill files or cancel signals.
Cross-posting. It doesn't solve or eliminate some problems.
Many disciplines have relevance to cross-postings.
Part of the problem is technical. Some news systems don't allow cross-posts.
Killfiles: If YOUR site doesn't have killfiles, it's your responsibility
to go to your news provider and ask for a full function news system,
so you can search, cancel, kill, cross-post, etc.
The transient nature of the m.j* readership makes this hard, but that's life
on the Usenet.
Robomoderation
-----
Moderation is double-edged sword. It's disadvantage is that it takes
someone's time, and we don't pay for that time. One proposal is to have a
network daemon make some simple agreed upon restrictions. We will have to
iterate these criteria.
By inclusion (these are some examples):
A maximum of three crossposted groups
/Newsgroups: [^,]*,[^,]*,[^.]*$/h
If there is a robomoderated entry group:
/Experience: 0.* years/
If there is no recruiter group, but a keyword robomoderated group
/Subject: RECRUITER:/h
Or follow up policy
/Followup-To: misc.jobs.misc/h
By exclusion:
Followups to inappropriate groups
/Subject: Re:/
Additional ideas:
- crossposting allowed only to newsgroups within the mjo hierarchy.
[I have problems with this --enm, (suggester now retracts this.)]
- posts from known recruiters will automatically be tagged if their
subject line does not already indicate this.
- Subject line format will be enforced.
[Content formating can also be enforced, but I oppose that to a
degree. --enm]
- Followup-to: should be left alone if it's ``poster''.
- Rather than put the recruiter tag in the subject line, perhaps we
could actually use the Keywords: line?
If a post does not meet these criteria, then poster gets the article back.
The problem is the reliability of mail (mail isn't reliable; that's
a VERY real problem [Trust me on this one, it used to be in my sig]).
Robomoderation won't be perfect, I can guarantee it's going to have problems
at the start, but, I'll willing to deal with them.
Other problems or issues?
=========================
You (the readership) fill these in.
The idea is that your commentary now, unlike past m.j.m. commentary is
"official." All those things you guys have spouted before didn't amount
to a hill of beans until this moment. It's up to you to convince me and
the rest of the readership what has to change so we can vote on this.
I am merely providing the mechanism. In the case of the straw poll, I write
that part of the ballot, so you have to convince me of the points to vote
and then I will have to write a proposal for Phase II which best suits a
reorganization.
Omni Consumer Products (OCP).
"If they can't take jokes, farg them."
--William Thacker, 1st moderator of sci.military
Eugene N. Miya
news.groups,misc.jobs.misc
crosspost and NOT strictly keep it in news.groups. Network connectivity
has been bad for the past couple of months, and this will test whether
the crossing helps. If we don't see your comment, that's your tough beans
when I try to summarize the weekly discussion.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
Resident Cynic, Rock of Ages Home for Retired Hackers
{uunet,mailrus,other gateways}!ames!eugene
My 2nd favorite use of a flame thrower is the remake of "The Thing."
A Ref: Uncommon Sense, Alan Cromer, Oxford Univ. Press, 1993.
Joel Plutchak
First off, it would be nice to identify the other contributors to
this RFD. I know who "Stern" is; who are the others?
>The following starts an official restructuring of the misc.jobs.* hierarchy.
>The reorganization will be done in two-parts:
...
>Phase I: Misc.jobs.offered.entry
>================================
>
>Misc.jobs.offered.entry:
>M.j.o.e. was created under the auspice of a six-month test-period as was
>pointed out by several m.j.m posters.
Yup, and it never worked, and hence should have been removed a year
ago.
>The question at hand in Phase I is:
> Should we remove misc.jobs.offered.entry?
Yes.
>Misc.jobs.resumes
>-----------------
>
>Misc.jobs.resumes: unchanged as proposed.
>A computer vs. non-computer split has been proposed in m.j.m. at one time.
Leave it unchanged.
>Misc.jobs.contract
>-------------------
>
>Misc.jobs.contract: unchanged as proposed.
Unchanged.
>Misc.jobs.misc
>--------------
>
>Should misc.jobs.misc be renamed (Snoop's position)?
> Suggested renamings are:
> No change.
> misc.jobs.d # traditional Usenet/MIT LISP-ish way
> misc.jobs.discuss # Linda Richman's SNL method
> misc.jobs.discussion # English teacher/student proposal*
>M.j.m is the discussion group for various job related issues not merely
>to discuss the m.j.* hierarchy:
>salaries, vacation policies, should I lie on my resume,
>how do I ask for a reference, what do I do about my stupid boss.
Change the name. I prefer either m.j.discuss or m.j.discussion.
There has been an increasing number of job openings and resumes
posted there. I believe making the name more explicit would help
such articles get to the proper newsgroups.
>Misc.jobs.offered
>-----------------
>Misc.jobs.offered removed and replaced with a hierarchical base of one or more
>of the following dimensions (note we face what the programming language
>people call "the orthogonality problem" for each dimension, we have that many
>subdimensions we will have to face; so consider your choices wisely):
>
> Recruiter split
> Geographic split
> Hierarchy by job description starting with a computer/non-computer split
> Robomoderation
I support robomoderation. The number one reason is to enforce a
Followup-To line to the appropriate place. I think it would also
help cut down the noise in other ways, too, e.g. making it more difficult
for "MAKE MONEY FAST" and Canter & Segal type spamming. I could go
either way with enforcing some sort of subject-line content. One the
one hand, it definitely would make it easier for the knowledgeable
job-seeker to handle the newsgroup. However, if done too strictly,
it could act to stifle the occasional or casual job poster. (The one
thing many people seemed to overlook in some of the previous go-rounds
is that the newsgroup doesn't exist solely for the benefit of the
job-seeker, and that if job posters are discouraged from posting, it
will be to the detriment of the job-seeker.)
>Recruiters
>-----
>
>I've nothing against recruiters, and I don't appreciate the problem.
>You have to convince me of the problem and suggest what to do and how it should
>relate to the other dimensions of reorganization.
>Note: simply having this group name does not restrict outside cross posts.
>If an obnoxious recruiter exists, see the comment about Killfiles below.
>
>Use of keywords in Subject lines: This we have tested this extensively.
>It's unenforceable without moderation, and we have not reached consensus on
>their use. Moderation is time consuming.
>With one possible exception (See Robomoderation).
I could go either way on this one. In my experience, articles
posted by recruiters aren't very useful-- the content of the descriptions
are often laughably vague, they tend to screen using blatantly ridiculous
criteria, and I suspect many of the so-called positions are really trolls
for resumes. Some, too, seem to think that posting the same positions many
times each week is an effective use of bandwidth, which just increases noise
(IMO). However, I find it easy to kill off the bulk of the recruiter
postings, so I don't see separating recruiters from principals, either
by newsgroup or keyword, a significant issue at this time.
>Geographic:
>-----
I think geographical information is best left to keywording. That,
of course, presupposes some sort of moderation that enforces adequate
keywording. (By keywording, I mean any use of keywords in the "Subject"
line and/or the "Keywords" line.)
My impression is that posters have been getting better about
including some sort of geographic information in the subject line,
for what it's worth.
>Hierarchy by job description starting with a computer/non-computer split:
>-----
>
>We have looked at how newspapers do this. It's messy anyway you look at it.
>[We needn't emulate the current newspaper scheme, and are free to implement
>our own. -Steve]
>[Note: you have the same issue as with m.j.o.e: the non-computer
>job companies are less likely to be reading/using Usenet. If you build it,
>they won't necessarily come. A new misc.jobs.offered.medicine, for example,
>might be mostly empty -- better to read sci.med and look there.
>(In fact, as a real example, sci.geo.meteorology often contains position
>availability announcements.) -- Stern]
I'd like to see some sort of breakdown of current traffic (if I
had the time and a local news spool, I'd attempt it myself). I
recognize the difficulties in any hierarchial scheme, and really
wouldn't want to make any sort of suggestions without such a breakdown.
As I mentioned in the latest discussion, if you simply separate out
the very few non-computer postings, you're not helping the bulk of
the job-seekers *or* the job posters, so the total value of such
a trivial split is very low.
>Robomoderation
>-----
>
>Moderation is double-edged sword. It's disadvantage is that it takes
>someone's time, and we don't pay for that time. One proposal is to have a
>network daemon make some simple agreed upon restrictions. We will have to
>iterate these criteria.
>
>By inclusion (these are some examples):
> A maximum of three crossposted groups
> /Newsgroups: [^,]*,[^,]*,[^.]*$/h
> If there is a robomoderated entry group:
> /Experience: 0.* years/
> If there is no recruiter group, but a keyword robomoderated group
> /Subject: RECRUITER:/h
> Or follow up policy
> /Followup-To: misc.jobs.misc/h
>
>By exclusion:
> Followups to inappropriate groups
> /Subject: Re:/
May want to add certain popular subjects, e.g.
/MAKE.MONEY.FAST/
>Additional ideas:
>
> - crossposting allowed only to newsgroups within the mjo hierarchy.
> [I have problems with this --enm, (suggester now retracts this.)]
>
> - posts from known recruiters will automatically be tagged if their
> subject line does not already indicate this.
>
> - Subject line format will be enforced.
> [Content formating can also be enforced, but I oppose that to a
> degree. --enm]
>
> - Followup-to: should be left alone if it's ``poster''.
>
> - Rather than put the recruiter tag in the subject line, perhaps we
> could actually use the Keywords: line?
>
>If a post does not meet these criteria, then poster gets the article back.
>The problem is the reliability of mail (mail isn't reliable; that's
>a VERY real problem [Trust me on this one, it used to be in my sig]).
I would suggest a set of suggested guidelines for Subject/Keyword
content (e.g. at least state/country), with enforcement by benign
robomoderation. By that I mean all but egregiously inappropriate
articles would go through unchanged (except for Followup-To: line), but
non-conforming submitters also get auto-mailed the guideline FAQ.
>Other problems or issues?
>=========================
I think it's best to be fairly cautious with changes at this
point, so inappropriate choices aren't made that, due to the
nature of USENET, would be difficult to back out of. Changes
should be small, yet set the framework for further improvements
to the hierarchy. (I realize that statement clashes somewhat with
my observation under the Hierarchy discussion above. C'est la vie. :).
--
Joel Plutchak, Research Programmer/Analyst
Brown University Planetary Geology
http://lager.geo.brown.edu:8080/~plutchak/plutchak.html
Jim Jewett
Joel Plutchak <plut...@lager.geo.brown.edu> wrote:
|> In article <2vt31u$o...@rodan.UU.NET>
|> eug...@nas.nasa.gov (Eugene N. Miya) writes:
|> >M.j.m is the discussion group for various job related issues not merely
|> Change the name. I prefer either m.j.discuss or m.j.discussion.
|> There has been an increasing number of job openings and resumes
|> posted there. I believe making the name more explicit would help
|> such articles get to the proper newsgroups.
Discussion? Cool, I can post my resume there! Given that a resume group
exists, I really don't think it will help all that much. This doesn't
mean that it isn't worth doing, of course, only that it won't help
as much as you hope it will.
|> >Misc.jobs.offered
|> >-----------------
[robomod thoughts. I'll metoo it.]
|> >Hierarchy by job description starting with a computer/non-computer split:
|> >-----
|>
|> I'd like to see some sort of breakdown of current traffic (if I
|> had the time and a local news spool, I'd attempt it myself). I
|> recognize the difficulties in any hierarchial scheme, and really
|> wouldn't want to make any sort of suggestions without such a breakdown.
|> As I mentioned in the latest discussion, if you simply separate out
|> the very few non-computer postings, you're not helping the bulk of
|> the job-seekers *or* the job posters, so the total value of such
|> a trivial split is very low.
Oh, but for those you help, it is wonderful... (Also note that they
may be the most likely to get overwhelmed by the current volumes.)
Me, I would look in both next time I job hunt. (err... just before
this passes, in the worst case...) But I could start trimming groups
with the next split. I could ignore _almost_ anything outside
computers, and I would ignore more of the computers stuff until I
got desperate.
If you want a split more like halving, split computers as well --
C[++] programmer vs everything else, for instance. (Last time I peeked
was about a year ago...)
_________ Have a favorite group or mailing list? Describe it to
| grou...@pitt.edu
jJ | Take only memories. ji...@eecs.umich.edu
\__/ Leave not even footprints. jew...@pitt.edu
Brad Appleton
>In article <2vt31u$o...@rodan.UU.NET> eug...@nas.nasa.gov (Eugene N. Miya) writes:
>>Phase I: Misc.jobs.offered.entry
>>================================
Should have been removed long ago. Do it now while we can!
>>Misc.jobs.resumes
>>-----------------
Leave it unchanged.
>>Misc.jobs.contract
>>-------------------
Ditto (Unchanged)
>>Misc.jobs.misc
>>--------------
Either leave the name as it is or use "misc.jobs.d"
(I have no strong preference either way).
>>Misc.jobs.offered
>>-----------------
>> Recruiter split
>> Geographic split
>> Hierarchy by job description starting with a computer/non-computer split
>> Robomoderation
I think Robomoderation is a *must*, but a split may also be
necessary or desireable. I like the job-description hierarchy split
*far* better than the others.
>>Robomoderation
>>-----
This could solve several of the following problems:
1) offers crossposted to misc.jobs.misc
2) followups to a post on misc.jobs.offered
3) spamming ("MAKE MONEY FAST" and "SKINNY DIP" schemes & scams)
4) incomplete/uninformative subject lines
5) posting the same position 20 times in one week (maybe??)
My idea for robomoderation is different from the inclusion/exclusion
methods in your post (although not exclusive of them). I also think
the robomoderator needs to "remove" misc.jobs.misc from the job-offer
post, and ensure that followups do NOT go the the jobs-offered
newsgroup. I agree that certain subjects/authors could be flagged for
inclusion/exclusion, but I also think subject line format should be
enforced.
Basically what I want (besides title/location/employer) is some
indication in the subject line of all of the following (if space does
not permit, some could be moved to the keyword line):
- is this solicited by recruiter?
- is the position contract, consulting, or temporary?
- is the position entry-level?
- is the position part-time?
If any of the above are true, I think there should be a special tag
on the subject line (or keyword line).
My idea is to require four or so auxiliary headers at the
beginning of the article (like *.answers uses) that would be required
to occur immediately after the standard news headers (but perhaps
separated by one or more blank lines):
| Position: <1-4 word description of position>
| Location: <succinct description of job location>
| Employer: <name of employer> [ Optional, but recommended ]
| Solicitation: direct | consulting | recruiter | agency | search-firm
| Term: permanent | temporary | contract
Perhaps another header could be used to determine ENTRY-LEVEL status,
but we should keep the number of required headers to a minimum
(somewhere between 3-6, preferable closer to 3). Note the we could
encourage (but not require) the user of other auxiliary headers as
well (but Im not sure if that would be good or bad). Perhaps
solicitation, term, entry-level, and full/part time could be combined
into a single header-line like:
| <some-header-name-here>: keyword [, keyword ...]
Where certain keywords would cause extra stuff to be added to the
subject-line.
Anyway, the basic idea is that the robomoderator reads these auxiliary
headers and actually composes/replaces the subject line of the post
in the required format (perhaps it would add some keywords to the
"Keywords:" line as well).
If the required auxiliary headers were NOT present, or the "Term:" or
"Solicitation:" headers did *not* have one of the acceptable values,
then the article would be "bounced", but the reply would have to
include instructions on how to fill in these auxiliary headers (an FAQ
with such instructions would also be good).
Some other (unpublished) mechanism could be used to make sure FAQs were
not bounced. My main concern with this approach is that it could be
(to some extent) circumvented by obnoxious recruiters or consulting
firms that would deliberately *not* indicate that they are recruiter
or consultants!
>I would suggest a set of suggested guidelines for Subject/Keyword
>content (e.g. at least state/country), with enforcement by benign
>robomoderation. By that I mean all but egregiously inappropriate
>articles would go through unchanged (except for Followup-To: line),
>but non-conforming submitters also get auto-mailed the guideline FAQ.
I dont think that will be enough, but id be willing to give the above idea
a try (but I still think the auxiliary headers could be used here as well).
Its just that if, after some period of time, this approach does not work,
and the problem is *NOT* due to unreliability of e-mail response, then I
would like to see the "robomoderation become more strict (less benign).
--
Brad.A...@mail.csd.harris.com Harris Computer Systems, Fort Lauderdale
"And miles to go before I sleep." DISCLAIMER: I said it, not my employer!
Eugene N. Miya
(Joel Plutchak) writes:
> First off, it would be nice to identify the other contributors to
>this RFD. I know who "Stern" is; who are the others?
Snoopy, Hollasch had repeated consultations (and I even lucnhed with Steve).
A couple of other local sys admins for Silicon Valley start ups who have
asked for anonmity (single inputs).
>>Other problems or issues?
>>=========================
> I think it's best to be fairly cautious with changes at this
>point, so inappropriate choices aren't made that, due to the
>nature of USENET, would be difficult to back out of. Changes
>should be small, yet set the framework for further improvements
>to the hierarchy. (I realize that statement clashes somewhat with
>my observation under the Hierarchy discussion above. C'est la vie. :).
This is why I thought up the two-part reorganization.
We start with a simple issue and also take a poll, then bu the big reorg.
It's a pilot study. Four months isn't too long to wait.
Chalk it up to net.experience.
>>The following starts an official restructuring of the misc.jobs.* hierarchy.
>>The reorganization will be done in two-parts:
>...
>>Phase I: Misc.jobs.offered.entry
>>================================
>>The question at hand in Phase I is:
>> Should we remove misc.jobs.offered.entry?
>
> Yes.
Votes don't count in this phase. That's the CFV phase.
Phase II:
These are straw poll structuring questions.
>>Misc.jobs.resumes
>>-----------------
> Leave it unchanged.
>
>>Misc.jobs.contract
>>-------------------
> Unchanged.
I have received some input for restructuring this group.
>>Misc.jobs.misc
>>--------------
> Change the name. I prefer either m.j.discuss or m.j.discussion.
>There has been an increasing number of job openings and resumes
>posted there.
I suspect (know) that name changing probably won't help.
I would bet money on it.
>>Misc.jobs.offered
>>-----------------
>>Misc.jobs.offered removed and replaced with a hierarchical base of one or more
>
> I'd like to see some sort of breakdown of current traffic (if I
Sorry, no stats. That's why the straw poll.
> I would suggest a set of suggested guidelines for Subject/Keyword
>content (e.g. at least state/country), with enforcement by benign
>robomoderation. By that I mean all but egregiously inappropriate
>articles would go through unchanged (except for Followup-To: line), but
>non-conforming submitters also get auto-mailed the guideline FAQ.
We have them. And this is all assumed in the proposal for Robo Moderation.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
Vice President, m.j.m. Omni Consumer Products reorg effort
Matthew T. Adams
Regarding the restructuring of misc.jobs.*, I think it would be
wise to reorganize the groups by looking at what is now (supposed
to be) required in the subject line: job title, company offering
the position, and location.
In my experience, albeit limited, it seems as though location is
one of the most important factors if one is searching for a
permanent position; in the case of a contract position, however,
mobility is expected to a certain degree. So, my suggestion would
be to extend the current groups to macro-sized subcategories, and,
in the event traffic becomes excessive, further extend the groups
into micro-sized categories. This approach would suggest the
elimination of regional groups (ie, ba.jobs.offered, etc), in favor
of this convention (pardon the computer- & US-centricity). Besides,
posters can regionalize their distribution in the "Distribution:" line.
m.j.o.west-coast (CA,OR,WA,HI,AK)
m.j.o.south-west (NV,AZ,NM,UT)
m.j.o.mountain-states (MT,ID,WY,CO)
m.j.o.midwest (ND,SD,NE,KS,OK,TX,IA,MO)
m.j.o.new-england (MA,VT,NH,CT,ME,NH)
m.j.o.great-lakes (MN,WI,MI,IN,IL)
m.j.o.northeast (NY,NJ,PN,DE,MD,WV,VA,OH)
m.j.o.southeast (FL,GA,SC,NC)
m.j.o.south (LA,AK,MS,TN,KT,AL)
If, say, m.j.o.west-coast became flooded, you could then break it down
further into m.j.o.north-west and m.j.o.ca. If m.j.o.ca then became
flooded, break it further into m.j.o.northern-ca and m.j.o.southern-ca.
I would also suggest the same with m.j.contract. As for m.j.o.entry,
there is very little traffic, so I would leave it alone. The people
reading that group are also much more likely to be mobile than those
who are reading misc.jobs.offered.*, for whom relocation often entails
selling real estate, moving kids, etc.
I also feel that robomoderation would be a good way to implement
some standardization of job titles ("Software Engineer" vs
"Programmer/Analyst" vs "Data Modellor" vs etc...). This would
allow for conventional coding, where a title could have two
components: level and code. Levels could be something like
A Entry level (0-1 yrs)
B Jr level (1-3 yrs)
C Mid level (3-5 yrs)
D Sr level (5+ yrs)
and codes could be something like
SWE software engineer, general
FWE firmware engineer, general
HWE hardware engineer, general
HWEGr hardware engineer specializing in graphics boards
SWEComm software engineer specializing in communications
SWEGui software engineer specializing in graphical user interfaces
You could also encode specific areas of interest like C (C language), C++,
UNIX, OOP, VisB (Visual Basic), TC++ (Turbo C++), INGRES, MSWin3.1, NT,
X, X.25, TCP/IP, (comm protocols) etc.
So, for example, the subject line for a jr level GUI sw engineer position
from ABC Software Solutions for C/C++ in UNIX would look like
B-SWEGui;ABC Software;C,C++,UNIX;any additional info here
The use of separators (';' vs ',') could also help reliably filter through
unwanted postings.
So, what do you think?
Matthew
____________________
mta...@columbine.hsc.colorado.edu
Matthew T. Adams
University of Colorado Health Sciences Center
4200 E 9th Ave, C268-68
Denver, CO 80262
Eugene N. Miya
mta...@columbine.hsc.Colorado.EDU (Matthew T. Adams) writes:
>(pardon the computer- & US-centricity).
I have to reject any commentary which is US-centric, the net is much larger
than that, and any proposal has to address the entire net. You have to
either consider the rest of the world in this proposal (I noted this in
the RFD, and was asked to include it by other consultants). This is not
an exercise to be filled in by other readers of the rest of the world.
When you have filled in the rest, I will append it to the RFD 1st week summary.
Fortunately that's in the prioritizing straw poll part of the proposal
in part I. And you don't have to vote on that section for three months.
>Regarding the restructuring of misc.jobs.*, I think it would be
>wise to reorganize the groups by looking at what is now (supposed
>to be) required in the subject line: job title, company offering
>the position, and location.
Nothing is required. You can just put "Resume" or nothing and it will fly.
>into micro-sized categories. This approach would suggest the
>elimination of regional groups (ie, ba.jobs.offered, etc), in favor
We have no authority over regional groups.
>of this convention (pardon the computer- & US-centricity). Besides,
>posters can regionalize their distribution in the "Distribution:" line.
....
>I also feel that robomoderation would be a good way to implement
We don't know if it will work.
>components: level and code. Levels could be something like
>
>A Entry level (0-1 yrs)
Previous discussion set 0-2 years.
>B Jr level (1-3 yrs)
>C Mid level (3-5 yrs)
>D Sr level (5+ yrs)
>
>and codes could be something like
>
>SWE software engineer, general
>FWE firmware engineer, general
...
I can tell you right now obscure codes won't fly.
>B-SWEGui;ABC Software;C,C++,UNIX;any additional info here
Just calling it as I see it.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
Edward Vielmetti
Career Center and Medsearch America member companies use to post
job openings and handle incoming resumes. The objective is to make
sure that people using OCC and Medsearch fit in as well as possible
with misc.jobs.* and have good results from their recruiting efforts.
We also take in job listings from misc.jobs.offered, and presumably
from any other *.jobs.* subgroup with a high enough concentration
of relevant postings, and put them into the Online Career Center
servers - web server at http://occ.com/, gopher server at
gopher.msen.com.
The one thing that is absolutely the most important in any of
these cases where we take jobs (or resumes) in from the net and
add them to our server is deducing the location of the position
or desired location of the person looking for work - let me put
a closer point on it -
Location, location, location.
I'd go so far as to suggest that a robo-moderation strategy that
only required a
Location:
header be present in every article.
Edward Vielmetti, vice president for research, Msen Inc. e...@Msen.com
Msen Inc., 320 Miller, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)
msen info addresses: in...@msen.com - $20/mo public access Internet
occ-...@msen.com - Online Career Center jobs database
Joel Plutchak
>In article <2vu6ec$n...@cat.cis.Brown.EDU> plut...@lager.geo.brown.edu
>(Joel Plutchak) writes:
>>>The question at hand in Phase I is:
>>> Should we remove misc.jobs.offered.entry?
>>
>> Yes.
>
>Votes don't count in this phase. That's the CFV phase.
Yes, but this is the discussion phase, wherein we can hope to
let people know what the issues are, and lobby for our positions.
Once the first CFV goes out and the votes start rolling in, it'll
be too late.
>>>Misc.jobs.misc
>>>--------------
>> Change the name. I prefer either m.j.discuss or m.j.discussion.
>>There has been an increasing number of job openings and resumes
>>posted there.
>
>
>I suspect (know) that name changing probably won't help.
>I would bet money on it.
I'll stack my USENET experience (which started in the ihnp4/seismo
era) experience against your most likely equal or better experience, and
continue to disagree. If the change comes to pass and I'm wrong, I'll
buy you lunch next time I'm out at Ames. ;)
Right now, the misc.jobs.misc name relates very well to the catch-all
section in the newspaper categorization so familiar to those who
traditionally post jobs (in any media). The typical USENET jobs
newsgroup newbie looking to post a job opening will see a much
stronger logical association with a misc.jobs.misc newgsroup
than with a misc.jobs.discussion newsgroup, and post or crosspost
to the "misc" newsgroup. (I haven't checked yet, but if there
are as many job openings posted in the misc.jobs.resumes newsgroup
as there are in the misc.jobs.misc newsgroup, I'll concede the
point.)
Ilana Stern
>
> I also feel that robomoderation would be a good way to implement
> some standardization of job titles ("Software Engineer" vs
> "Programmer/Analyst" vs "Data Modellor" vs etc...). This would
> allow for conventional coding, where a title could have two
> So, for example, the subject line for a jr level GUI sw engineer position
> from ABC Software Solutions for C/C++ in UNIX would look like
> B-SWEGui;ABC Software;C,C++,UNIX;any additional info here
If you for one moment think that Joe Humanresources from ABC Software
is going to go to the trouble of conforming to this rather arcane
form, you are naive.
If you for one moment think that the readership of m.j.o would prefer
Joe's posting to be dumped by the moderator, rather than having a
stupid and uninformative subject line posted, you are not looking
for a job.
If you for one moment think that a robomoderator could somehow
figure out an appropriate subject line such as this from the body
of the posting, you are welcome to write the code to do it! :-)
--
/\ The truth is not known except to the wise, | dod#0009 cliff swallow
\_][ who drink it from the foaming coffee cup. | il...@ncar.ucar.edu
\__<a href=ftp://ncardata.ucar.edu/catalogs/.html/me.html>Ilana Stern</a>
Karen Jackson
frustrated to find only NY or CA jobs when I select Iowa, for example,
on the Online Career Center job listings. In fact many jobs seem to be
cross posted to *many* states that are very unlike NY and CA. Some will
even say "in midwest in Iowa" and the job location is NYC. Hopefully
this can be minimized on misc.jobs.
Just my $.02
Karen Jackson -- acsj...@acs.eku.edu
Eugene N. Miya
In article <300ni1$t...@cat.cis.Brown.EDU>
plut...@lager.geo.brown.edu (Joel Plutchak) writes:
> I'll stack my USENET experience (which started in the ihnp4/seismo
>era) experience against your most likely equal or better experience, and
>continue to disagree. If the change comes to pass and I'm wrong, I'll
>buy you lunch next time I'm out at Ames. ;)
Okay.
I'll let you make the decision if you want to concede the point based on
your metric (if (offerings(misc.jobs.resumes) > offerings(misc.jobs.misc))
exit();).
How do these conditions sound: assuming we rename (the Snoopy request, I
don't care myself, so we might as well call this off if we don't rename)
If after 1 month there's at least an offering a day in the renamed m.j.d.,
then the condition has been met? Hey, if you are visiting, you might get
lunch anyway.
Experience: ARPAnet 1973. UUCP in 1980, Usenet 1982 from the ames-lm!hao days.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
Peter C McCluskey
>A computer vs. non-computer split has been proposed in m.j.m. at one time.
I find it useless as is. A split such as:
m.j.r.software
m.j.r.hardware
m.j.r.non-computer
might make it usefull.
>Should misc.jobs.misc be renamed (Snoop's position)?
> misc.jobs.discuss # Linda Richman's SNL method
Yes.
>Misc.jobs.offered
>-----------------
> Hierarchy by job description starting with a computer/non-computer split
This is the most important. I suggest:
m.j.o.software.c++
m.j.o.software.c
m.j.o.software.smalltalk
m.j.o.software.database
m.j.o.software.sysadmin
m.j.o.software.misc
m.j.o.hardware
m.j.o.non-computer
> Robomoderation
Good idea.
> Recruiters
I doubt that any solution could be enforced, even with robomoderation.
--
-------------------------------------------------------------------
Peter McCluskey | p...@world.std.com | Repeal Gresham's Law!
-------------------------------------------------------------------
Crispin Cowan
Peter C McCluskey <p...@world.std.com> wrote:
>> Hierarchy by job description starting with a computer/non-computer split
> This is the most important. I suggest:
> m.j.o.software.c++
> m.j.o.software.c
> m.j.o.software.smalltalk
> m.j.o.software.database
> m.j.o.software.sysadmin
> m.j.o.software.misc
> m.j.o.hardware
> m.j.o.non-computer
The trouble with this scheme is that it obviously reflects your search
criteria. Mine are different, and would look like:
m.j.o.research <--- where I wanna be.
m.j.o.development <--- all that other irrelevant stuff :-)
m.j.o.support <--- ...
m.j.o.tech-writing
m.j.o.sales
m.j.o.non-computer
However, I don't for a second believe that either mine or yours will
suit most people. Someone else might want:
m.j.o.hardware
m.j.o.real-time
m.j.o.database
m.j.o.os
m.j.o.compilers
m.j.o.pc
While another party might want:
m.j.o.architecture
m.j.o.data-comm
m.j.o.chip-fab
m.j.o.software
I don'te believe in the existance of a fits-everyone split, so I oppose
the job description split. Lump it all in one group with ample
keywords enhanced as much as possible by robomoderation, and do your
own filtering.
Crispin
-----
Crispin Cowan, CS PhD student, searching for a research position
University of Western Ontario
Phyz-mail: Middlesex College, MC28-C, London, Ontario, N6A 5B7
E-mail: cri...@csd.uwo.ca Voice: 519-661-3342
"A distributed system is one in which I cannot get something done
because a machine I've never heard of is down" --Leslie Lamport
Edward Vielmetti
: On the effectiveness on renaming misc.jobs.misc to misc.jobs.discussion
: plut...@lager.geo.brown.edu (Joel Plutchak) writes:
: > I'll stack my USENET experience (which started in the ihnp4/seismo
: >era) experience against your most likely equal or better experience, and
: Experience: ARPAnet 1973. UUCP in 1980, Usenet 1982 from the ames-lm!hao days.
As long as we're waving credentials around (NNTP 1987, from
the mailrus!ames days) - renaming individual groups without
a complete re-org of the surrounding hierarchy hardly seems
to have overwhelming precedent.
If you are going to split m.j.o then perhaps every splittage
gets its own discussion group
m.j.healthcare.offered
m.j.healthcare.resumes
m.j.healthcare.discussion
m.j.computers.offered
m.j.computers.resumes
m.j.computers.discussion
m.j.education.offered
m.j.education.resumes
m.j.education.discussion
m.j.misc.offered
m.j.misc.resumes
m.j.misc.discussion
Where the "discussion" group gets the usual chatter about prospects
in the field, employer gossip, etc.
Sections taken from the Sunday NY Times display job classifieds (might
as well go up against a big target) and from an observation of what
kinds of stuff is out there in big quantity on the net; suggest
that these sorts of groups be created in 3s. I suspect you could
do "engineering" without too much trouble here too.
Joel Plutchak
>In article <CswLC...@world.std.com>,
>Peter C McCluskey <p...@world.std.com> wrote:
>>> Hierarchy by job description starting with a computer/non-computer split
>> This is the most important. I suggest:
>> m.j.o.software.c++
>> m.j.o.software.c
>> m.j.o.software.smalltalk
>> m.j.o.software.database
>> m.j.o.software.sysadmin
>> m.j.o.software.misc
>> m.j.o.hardware
>> m.j.o.non-computer
>
>The trouble with this scheme is that it obviously reflects your search
>criteria. Mine are different, and would look like:
>
>m.j.o.research <--- where I wanna be.
>m.j.o.development <--- all that other irrelevant stuff :-)
>m.j.o.support <--- ...
>m.j.o.tech-writing
>m.j.o.sales
>m.j.o.non-computer
I think your conception looks more reasonable than some programming
language based split. To me, the language based split is sorta like
assuming all auto mechanics only know how to service one brand of
vehicle, e.g. only a Ford mechanic can work on a Ford, since those
GM mechanics just don't have the right knowledge.
>However, I don't for a second believe that either mine or yours will
>suit most people.
...
>I don'te believe in the existance of a fits-everyone split, so I oppose
>the job description split. Lump it all in one group with ample
>keywords enhanced as much as possible by robomoderation, and do your
>own filtering.
Yup, that's the problem with categorizing by type.
--
Joel Plutchak, Research Programmer/Analyst, Brown University Planetary Geology
"I expect to visit Chico [CA] only one time during my life, as I do not
plan on leaving once I get there." - Tim McNerney on Sierra Nevada brews
Jim Jewett
Crispin Cowan <cri...@csd.uwo.ca> wrote:
|> In article <CswLC...@world.std.com>,
|> Peter C McCluskey <p...@world.std.com> wrote:
|> >> Hierarchy by job description starting with a
|> >> computer/non-computer split
[suggestion of a software split, on c, c++, smalltalk, also databases...]
|> The trouble with this scheme is that it obviously reflects your search
|> criteria. Mine are different, and would look like:
[research, development, sales, support...]
[others]
|> I don't believe in the existance of a fits-everyone split,
True.
|> so I oppose the job description split.
Disagree. Under every one of the (so far) proposed hierarchies, I would
be able to ignore several groups (unless I got _very_ desperate).
|> Lump it all in one group with ample keywords
Are you offering to add the keywords for the hundreds who don't? I suppose
you can just ignore anyone who doesn't use keywords. _I_, however,
wouldn't expect all potential job posters to be familiar with headers that
are often overlooked. (Quick, what keywords were we using for this?)
Right now I'm working as a research programmer at a University, but my
boss doesn't even know what usenet is. (I found the job through a
mailing list, but if we get the grant, I'll probably post the next
opening. I will _probably_ remember to include keywords.) I'm still glad
I found out about the job though, and wouldn't want a similar opportunity
to be missed because I needed keywords to wade through the morass.
On the other hand, most people placing an ad _do_ know whether they are
looking for hardware or software, what the platform will be, what the
language will be, whether it is research, what the topic will be,
etc, and once they've found the jobs hierarchy, they can be expected
to choose wisely from a small list of subgroups.
Crispin Cowan
Jim Jewett <ji...@quip.eecs.umich.edu> wrote:
>In article <3027d5$r...@falcon.ccs.uwo.ca>,
>Crispin Cowan <cri...@csd.uwo.ca> wrote:
>|> Lump it all in one group with ample keywords
>Are you offering to add the keywords for the hundreds who don't? I suppose
>you can just ignore anyone who doesn't use keywords. _I_, however,
True, not everyone uses keywords. In fact, I ignore that particular
field as well. What I do is just tell the newsreader to troll the full
text of the article for my list of keywords, as follows:
THRU 90148
/optimism/a:+
/optimistic/a:+
/PhD/a:+
/Ph.D/a:+
/faculty/a:+
/fellow/a:+
/research/a:+
/distributed/a:+
This does get a fair number of bogus hits (ads where the poster has a
PhD, people looking for microbiology faculty, and most especially,
ads for development people that have "researc" in their name
somewhere), but only hits about 10% of m.j.o, and I think does a
reasonable job of capturing ads that I'm interested in.
Question: do any of the proposed splits include keywords that are too
common to use the above approach? For instance, if you're only
interested in jobs concerning "newsgroups", then this thing will hit
every article, because they hall have a "Newsgroups:" line.
Steve Hollasch
> [regarding recruiters]
> I doubt that any solution could be enforced, even with robomoderation.
by any means, but merely tag them. Some folks use recruiters as a resource,
some folks don't want to deal with them.
Tagging via robomoderation is fairly simple - first, ask recruiters to
self-tag, according to whatever format we decide on. This could be work in
the subject line or in the keywords line. For those recruiters who don't
self-tag, the robomoderator could check the poster's address and tag if it
exists on a list of recruiters. The list could be expanded as needed. Yes,
some will slip through, but this would tag the vast majority.
Our primary goal is not to _filter_ posts, but to _classify_ them.
Eugene and I came to the conclusion that it's very reasonable to expect the
job-seekers to know how to use KILL files to aid their job search. In
addition, there's the assumption that the technical expertise of the
*posters* is very low (HR depts.).
What do folks think, by the way, about using the keywords: line? I
think that robomoderation could make good use of this header line.
Eugene N. Miya
(Crispin Cowan) writes:
>Question: do any of the proposed splits include keywords that are too
>common to use the above approach? For instance, if you're only
>interested in jobs concerning "newsgroups", then this thing will hit
>every article, because they hall have a "Newsgroups:" line.
You are looking for name collisions?
I think that's more of an issue of tuning the regular expression strings
used in searching on the Killfiles. The Robomoderator could do some
of that, but without moderation (and I am getting a few "opposed" comments),
keywords would be worthless. Steve over lunch said it best,
"We must assume that readers know how to use Killfiles." (paraphrased)
To give you an idea how I am judging some of this, I take the
case of my dear friend Steve X. [not Holl.]. He (not reading these
groups much) posted an unusual offering asking for help working on his
human powered vehicle (you might remember this incident). I think
the proposal has to allow the widest ranging free speech possible.
Any proposal has to be able to work for something as out of the
ordinary as Steve's post. He has that right to format as freely
as possible. It was a job offering, and thus belongs in mjo.
I have not set specific names to news groups or directories.
The intent of the straw poll is to prioritize any possible split
(geog/profession/recruiter/...). I am getting suggestions to split
resumes and contracts as well which were not on the original proposal,
but I will include in the straw poll.
"Mr X. Mr. X. Why are you named X."
"It's algebra..." --Malcolm X.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
net.ranger, net.ronin, net.bicyclist on the info superhighway (splat)
Eugene N. Miya
(Steve Hollasch) writes:
> What do folks think, by the way, about using the keywords: line? I
>think that robomoderation could make good use of this header line.
Personally, I think it's doomed to failure, but hey, what do I know?
I merely maintain one of the FAQs and am overseeing the proposal.
1) Killfiles use Subject: lines as the default. This is a problem.
2) Use of any other line: From:. Keyword:, etc. requires that a user
get into the Killfile and edit, and that means vi for many and emacs for
fewer, and we have lots of people who used news and don't know how to use
these editors (downloading and editing from other editors [they don't
know how to change editors in many cases]).
3) Editing kill files isn't simple (easier than editors, but you have to
be careful). I think cross posting will be a bigger problem as well as
dumb Subject lines (e.g. Resume ....).
4) We have to be careful using the robo moderator, Robo could be easily
corrupted for other purposes. He will be able all, merely a machine.
The evil comes from two cross-posted groups and Robo just giving approval,
that would definitely piss off the human moderator.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
Associate Editor, Software and Publication Reviews
Scientific Programming
{uunet,mailrus,other gateways}!ames!eugene
Seeking Books to buy: Bongard, Pattern Recognition
3 down 1 to go.
Don Marti
almost anywhere, for the right job. A geographical split won't
help wandering specialists at all.
Is there a Thomas Jefferson among us? Someone interested
in, and qualified for, _any_ job in "misc.jobs.offered.us.va"?
Someone, in short, who would get no help from a job title split?
(If you exist, you have improved your home town by your
presence, and you're right not to think of leaving. The world
needs more people like you.)
But unfortunately for humanity, we probably have more
wanderering specialists than Thomas Jeffersons. So I'm putting
in my straw poll straw for a job title split.
--
Don Marti
dma...@sun1.iusb.indiana.edu
Steve Hollasch
m.j.o.software.c++ m.j.o.hardware
m.j.o.software.c m.j.o.real-time
m.j.o.software.smalltalk m.j.o.database
m.j.o.software.database m.j.o.os
m.j.o.software.sysadmin m.j.o.compilers
m.j.o.software.misc m.j.o.pc
m.j.o.hardware
m.j.o.non-computer m.j.o.architecture
m.j.o.data-comm
m.j.o.research m.j.o.chip-fab
m.j.o.development m.j.o.software
m.j.o.support
m.j.o.tech-writing
m.j.o.sales
m.j.o.non-computer
cri...@csd.uwo.ca (Crispin Cowan) writes:
* I don't believe in the existance of a fits-everyone split, so I oppose the
* job description split. Lump it all in one group with ample keywords enhanced
* as much as possible by robomoderation, and do your own filtering.
Please note that what we are currently working on is NOT an exploded
327-group hierarchy. Rather, we're trying to establish consensus on the
PHILOSOPHY of future splits. Right now, there's no need to for
mjo.hotel-admin. If there is in the future, we can add that then, and
debate the pros and cons of that specific group. But we won't be slapping
down a proposal for every conceivable group at this point.
For example, the first split might simply be misc.jobs.offered.misc and
misc.jobs.offered.software. If you want to further split mjo.software by
language, project, or favored pen-holder, we can propose/debate that in the
future. But at least we'd know that we add new groups by classification of
job description, rather than geography. Or, if folks insist on a geography
split (which I desperately hope will not happen) then we'll know to further
subdivide the hierarchy, when needed, by location and not job description.
______________________________________________________________________________
Steve Hollasch Kubota Graphics Corporation
Jim Jewett
Eugene N. Miya <eug...@wilbur.nas.nasa.gov> wrote:
|> In article <1994Jul14....@kpc.com> holl...@kpc.com
|> (Steve Hollasch) writes:
|> > What do folks think, by the way, about using the keywords: line? I
|> >think that robomoderation could make good use of this header line.
Good utopia. Probably worth doing for auxilliary keywords.
|> 1) Killfiles use Subject: lines as the default. This is a problem.
And some readers apparently can't touch a keywords line. Yes, they're
broken, but they exist, and they work now...
|> The evil comes from two cross-posted groups and Robo just giving approval,
|> that would definitely piss off the human moderator.
This isn't too hard to check for, given that you're writing the robocode
anyhow. Just add in the automated checker if your system supports it,
or check the active file for an "m", or ...
Steve Hollasch
> What do folks think, by the way, about using the keywords: line? I
> think that robomoderation could make good use of this header line.
eug...@wilbur.nas.nasa.gov (Eugene N. Miya):
( Personally, I think it's doomed to failure, but hey, what do I know?
( I merely maintain one of the FAQs and am overseeing the proposal.
Give it a rest, Eugene; you're just trolling for another lunch bet,
aren't you? B^)
( 1) Killfiles use Subject: lines as the default. This is a problem.
(
( 2) Use of any other line: From:. Keyword:, etc. requires that a user get
( into the Killfile and edit, and that means vi for many and emacs for
( fewer, and we have lots of people who used news and don't know how to use
( these editors (downloading and editing from other editors [they don't
( know how to change editors in many cases]).
(
( 3) Editing kill files isn't simple ...
First of all, I just tried to add a /foo/h:j command to my header file
while using 'trn', and darned if you aren't right. At least, I couldn't
find a way to do it from a trn prompt. So I guess I'll have to *partly*
concede your point.
I don't think we should completely write off using the keywords line
altogether; if we can add additional classification for advanced users it
might still be worth it. But I guess that we should leave that for
future debate and stick to subject lines for the time being.
Michael Drews
the subject line. I have been building a KILL file for m.j.o for about
a year now, which has grown to 835 items (at last count). It gets this
large because of the large number of variations on words like "software,"
(31 entries with a capital "S") or "system manager." I've gotten my
KILL ratio up to about 80%, but a lot of garbage still sneaks through.
(Of course I tend to notice the odd misspellings, since the articles
that use proper keywords in the subject line get killed.) The "MAKE.
MONEY.FAST" posts don't bother me near as much now that I have that
title in my KILL file, but when a new variation comes along I find
it irritating.
In the ideal world, the "robomoderator" would reject a posting that
didn't use any of the official keywords, and include a list of suggested
keywords with the rejection message.
This robomoderator would help mostly those people who had learned to
use KILL files, and would probably be frustrating for the posters who
post one job per year. On the other hand, places like the Online
Career Center should have no problem sorting their postings into a
limited number of catagories. The official list of catgories could be
posted on a regular basis. New catagories could be added by request.
For example, there might be a massive need for tribologists. If this
word were not in the official list of keywords, they could be posted under
"Mechanical Engineer," and the "Tribologist" keyword requested from the
robomoderator administrator. In the meantime, software engineers could
be killing the "Mechanical" subjects, anthropologists could be killing the
"Engineer" subjects, and so forth.
Why not set up a hierarchy for different job catagories? It's too
cumbersome to add new catagories, would require too many catagories to
be useful, and would probably not be understood by the occasional user.
A hot new field might come up that would not fit into any catagories.
The robomoderator with enforced use of keywords would make life
harder for posters, but could make life much easier for people trying to
read the group. Even if they didn't know about kill files, at least
every posting would have something intelligible in the subject line,
instead of "USA.CA.415.INS.STAFFING" or "Programmmer."
Michael Drews
P.S. Thanks for the killfile line for postings to more than three groups.
--
----------
I'm not worried about the weather; the weather will do just what it wants.
Steve Hollasch
( Why not set up a hierarchy for different job catagories? It's too
( cumbersome to add new catagories, ...
I don't understand this assertion. Newsgroups are being created
every week. What about this process is different for the mjo hierarchy?
( ... would require too many catagories to be useful,
This is _really_ strange. Do you find that Usenet has too many
categories? Is it less useful to you because we have many newsgroups?
( and would probably not be understood by the occasional user.
We must assume that even the occasional user reads newsgroups by
selection.
( A hot new field might come up that would not fit into any catagories.
This is why we have foo.bar.misc groups.
Once again, a job-description split would bifurcate AS NEEDED, and as
decided by a specific vote. For example, a reasonable first-pass
fork of misc.jobs.offered would be misc.jobs.offered.software and
misc.jobs.offered.misc.
Eugene N. Miya
>holl...@kgc.com (Steve Hollasch) writes:
> Give it a rest, Eugene; you're just trolling for another lunch bet,
> aren't you? B^)
Me? Underpaid silly servant? Attempting to build an awesome information
infrastruction? Naw. The last bet was "who played Uncle Ernie in the film
Tommy?" I won that, but have yet to collect $5. I usually only bet when
I'm 90% certain. I'm no fun.
>( 3) Editing kill files isn't simple ...
> First of all, I just tried to add...
> So I guess I'll have to *partly* concede your point.
> I don't think we should completely write off using the keywords line
I think I'd like to see the Keyword use stay in the Subject: line.
To give a short status:
People have made suggestions for changing resumes and contracts.
I think I will elevate the status of the m.j.m. renaming to an
official question rather than straw question,
there appears to be serious interest in Snoop's idea.
Some people are completely opposed to reorganization.
Some recruiters have responded.
Offerings and resumes still appear in m.j.m., and discussion
and non-offerings appear in m.j.o.e.
Some responders have asked for anonmity (done).
I'll post a weekly summary on Monday.
--eugene miya, NASA Ames Research Center, eug...@orville.nas.nasa.gov
William J. Dcamp
to making any kind of sense is the suggestion for mjo.software and mjo.misc.
But what I'd rather see is a split such as mjo.computer and mjo.other.
This would at least provide the possiblity of separating out non-computer
oriented jobs, although given the amount of crossposting I've seen I'm not
convinced that any sort of split will really be effective. I'm strongly
opposed to any sort of geographic split, I presently live in Japan and the
system where I read news is in San Diego. Any sort of geographic split
would probably result my not being able to read anything but mjo.calif.
I have no idea who the news administrator is on this system, let alone
how I could influence him/her to carry mjo.everywhere after a geographic split.
Fortunately (for me) such a split seems unlikely.
I think that a separation of computer/non-computer makes a lot of sense, then
after we see how successful the split is we can add more specific groups
later as required.
Bill D'Camp
dc...@monkfish.nosc.mil
or
dca...@emh.yokota.af.mil
Martin Smith
> m.j.o.software.c m.j.o.real-time
> m.j.o.software.smalltalk m.j.o.database
> m.j.o.software.database m.j.o.os
> m.j.o.software.sysadmin m.j.o.compilers
> m.j.o.software.misc m.j.o.pc
> m.j.o.hardware
> m.j.o.non-computer m.j.o.architecture
> m.j.o.data-comm
> m.j.o.research m.j.o.chip-fab
> m.j.o.development m.j.o.software
> m.j.o.support
> m.j.o.tech-writing
> m.j.o.sales
> m.j.o.non-computer
I don't think splitting the jobs group like this will work because most
of the jobs require X *and* Y *and* Z, so the poster will simply replicate
the message in each of the three sublists. It will just increase the total
network traffic.
I think a very coarse split would work, perhaps: computer and non-computer,
or hardware, software, and non-computer.
martin
Paul Ortega
Brad Appleton <Brad.A...@mail.csd.harris.com> wrote:
>In article <2vu6ec$n...@cat.cis.Brown.EDU>, plut...@lager.geo.brown.edu (Joel Plutchak) writes:
>>In article <2vt31u$o...@rodan.UU.NET> eug...@nas.nasa.gov (Eugene N. Miya) writes:
>
>>>Phase I: Misc.jobs.offered.entry
>>>================================
>
>Should have been removed long ago. Do it now while we can!
I agree.
Entry-level positions can be posted with a zero in the "experience
required" key-line.
>>>Misc.jobs.misc
>>>--------------
>
>Either leave the name as it is or use "misc.jobs.d"
>(I have no strong preference either way).
I prefer "misc.jobs.d" to help prevent those with a clue from
posting resumes and job ads in misc.jobs.misc.
--
Paul Ortega ort...@io.com
.signature under construction
Poopie
I'll consider moving for a good programming job.
I won't consider becomming a finance major to stay in the midwest.
Geographical split: nay, type-of-position split: yea. (Should be simple split
like m.j.o.software, m.j.o.hardware, m.j.o.sales, m.j.o.other). I would
vote against any split that created more than a ten new groups. It
would be too much strain on the poster and they would subsequently not
follow the rules.
Srinivas Nedunuri
Christine Hogan <cho...@maths.tcd.ie> wrote:
>sr...@cs.utexas.edu (Srinivas Nedunuri) writes:
>> -- I dont thikn that a split of m.j.o into "US" and "non-US" is such
>> a bad thing.
>
>I'm afraid I disagree here. I feel that we should either split on location
>(which I don't want) or on "job title" (in some form). If someone is fussy
>about location they are going to be weeding out "all but areas A and B" by
>their kill-file anyway, so why a "non-US" group ? Besides, the people looking
>for jobs in "non-US" places are just as unlikely to be qualified for every
>possible job as people looking for US jobs.
Yes you're absolutely right, I am being inconsistent :-) The reason I suggested
it was to cater to the perhaps 5% of posting that are neither computer
oriented nor US-based. Folks interested in those two categories currently
need to download a mountain of job postings most of which are absolutely
irrelevant to them. Agreed there's probably other "minority" categories out
there that I'm ignoring but this one's easy to do :-)
>Also, minor nit-pick, for a moment I thought "non-us" meant "a group for jobs
>where US citezenship/green card isn't required". So this group also violates
>your principle of unambiguous names.
Agreed again. How about misc.jobs.us-based.... instead of misc.jobs.us.... ?
>I agree in principle, but when I was trying to place some jobs... like sysadmin
,
>tech writer and Professor in dept of CS... Hmm... software ? not really;
>hardware ? not really; non-computer ? no. Umm.
>
>So, I think we probably also need a catch-all group here (and pray that the
>HR people don't just shove everything there !). So... how about:
>misc.jobs.computer.software
>misc.jobs.computer.hardware
>misc.jobs.computer.other
>misc.jobs.non-computer
Yeah, I'm also concerned this catch-all group is going to be our undoing and
we'll woe the day we ever put it in. Two possible solutions are:
(1) Allow such jobs to be posted to both groups (ie.software and hardware)
or
(2) Unambiguously rename the other group eg. to misc.jobs.computer.sw-and-hw
instead of misc.jobs.computer.other
>> misc.jobs.non-us
>
>I vote to scrap this one !
That's your prerogative!
--srin;
Nick Jacobs
> -- I dont thikn that a split of m.j.o into "US" and "non-US" is such
> a bad thing.
I agree with this, despite the objections that have been raised.
There are very few people who want to read postings for jobs
in the USA, *and* for jobs outside the USA. It would be a useful
split. And I hope that we are trying to come up with a *useful*
split, not necessarily a split that is "logically satisfactory"
to the pedants.
Somebody objected that the effect of such a split could be
achieved by kill-file entries. That's not true, because
Subject lines even when they indicate location often make
the assumption that only the USA exists. (Location
indications like "Northwest", meaning Washington state/
Oregon). Also the kill-file argument could be raised to
just about any split of any group ever made.
I would expect that creation of a "non-us" subgroup would
result in a large increase in the number of job postings
for non-us jobs. At the moment, there are very few because
the group is virtually useless for such postings. In
time, the "non-us" would grow large enough to be split
again.
Nick
Michael Drews
> mdr...@iguana.dsd.es.com (Michael Drews):
> ( Why not set up a hierarchy for different job catagories? It's too
> ( cumbersome to add new catagories, ...
>
> I don't understand this assertion. Newsgroups are being created
> every week. What about this process is different for the mjo hierarchy?
official CFV, voting period, and so forth. Seems to me this is usually a
fairly long period (several months). It would be much easier just to add
the word "Sybase" to the official list or required keywords for the subject
line.
>
> ( ... would require too many catagories to be useful,
>
> This is _really_ strange. Do you find that Usenet has too many
> categories? Is it less useful to you because we have many newsgroups?
m.j.o.not-for-me. However, there are those who have chosen to specialize
in Sybase, and don't care about any of the system manager jobs, neither of
which interest me. Judging from the job descriptions in the subject lines,
I see somewhere between 50 and 100 job categories that could be in
separate groups. Those using geographical criteria to look for a job need
a different hierarchy.
> Once again, a job-description split would bifurcate AS NEEDED, and as
> decided by a specific vote. For example, a reasonable first-pass
> fork of misc.jobs.offered would be misc.jobs.offered.software and
> misc.jobs.offered.misc.
>
read beyond the subject line. If everybody else has the same kind of search
criteria, then there would need to be about 40 groups under m.j.o, assuming
a posting volume of 200 per day. Everybody has a different feeling for the
ideal amount of traffic in a newsgroup, but I consider 5 to 20 messages per
day to be ideal.
I'll try to extract a bunch of catagories from my kill file, to make a
first pass at some possible keywords for the subject line.
Michael Drews
--
-----------
"These aren't the droids you're looking for."
Michael Drews
You may notice that some are missing, like "Hardware," "Design," and
"Engineer." I tried to standardize capitalization in the file, with
acronyms fully capitalized, and the first letters of titles capitalized.
Sorry that it's in killfile format, one keyword per line, but that was
the relatively easy way to do it. Some way of refering to the programming
languages C and C++ that is less ambiguous would be helpful. This list is
good for about a 50% kill ratio in misc.jobs.offered. Hit "N"
now if you don't want to see 300 lines of job title keywords/phrases.
Michael Drews
****** Cut Here *****
/3D Animators/:j
/ADABAS/:j
/AIX Internals/:j
/AS.400/:j
/Account Exec/:j
/Account Manager/:j
/Accountant/:j
/Advertising/:j
/Allegro/:j
/Analog Design Engine/:j
/Analyst/:j
/Anethesia/:j
/Application Eng/:j
/Application Manag/:j
/Artificial Intelligence/:j
/Artist/:j
/Assist Prof/:j
/Atlanta/:j
/Australia/:j
/Automotive Truck/:j
/Banking/:j
/Bio.Mechanics/:j
/Biochemists/:j
/Biologist/:j
/Business Manager/:j
/Business Opportunity/:j
/Buyer/:j
/CAE Eng/:j
/CASE Consultant./:j
/CASE Tools/:j
/CFD Engineer/:j
/COBOL/:j
/Case Tools/:j
/Cellular Design/:j
/Check Processing/:j
/Chem. Eng/:j
/Chemist/:j
/Civil Engineer/:j
/Clerical/:j
/Client Executive/:j
/Client Manag/:j
/Client Services/:j
/Cobol/:j
/Communication Eng/:j
/Compiler/:j
/Computer oper/:j
/Consultant/:j
/Contract/:j
/Controls Engineer/:j
/Credit/:j
/Cust Support/:j
/DB2/:j
/DBA/:j
/DBMS/:j
/DOS/:j
/DSP Engineers/:j
/DSP Hardware/:j
/Data Architect/:j
/Design Verificati/:j
/Desktop Publish/:j
/Device Driver/:j
/Device Modelling/:j
/Die Cutter/:j
/Distributor/:j
/Doctoral/:j
/Documentation/:j
/EDI Analyst/:j
/EDI Prof/:j
/EIS/:j
/Editor/:j
/Educational/:j
/Electromechanical/:j
/Electronic Tech/:j
/Elementary Teacher/:j
/Embedded Control/:j
/Embedded SWE/:j
/Environmental/:j
/Europe/:j
/FAE /:j
/FORTRAN/:j
/Factory/:j
/Faculty/:j
/Fasteners/:j
/Field Engr/:j
/Financial/:j
/Firmware/:j
/Fluid Dynamics/:j
/FoxPro/:j
/GUI Devel/:j
/Generator/:j
/Government Job/:j
/Grad Asst/:j
/HOOPS/:j
/HP 3000/:j
/HVAC/:j
/Hardware Technician/:j
/Health Care/:j
/Hong Kong/:j
/Horticulturist/:j
/Hospital/:j
/Human Resource/:j
/IC Layout/:j
/IC Mask Design/:j
/IC Reliability Eng/:j
/INFORMIX/:j
/INGRES/:j
/IS Professional/:j
/IS Specialist/:j
/ISO 9000/:j
/Image Processing/:j
/Information Archi/:j
/Information Special/:j
/Information Sys/:j
/Information Tech/:j
/Informix/:j
/Ingres 4GL/:j
/Ingres Pro/:j
/Injection Molding/:j
/Instructor/:j
/Interactive TV/:j
/Internet Manag/:j
/Interviewers/:j
/Investment/:j
/JCL/:j
/LAN Admin/:j
/LAN Engineer/:j
/LAN Manager/:j
/LISP/:j
/Lecturer/:j
/Legal Examiner/:j
/Lending/:j
/Librarian/:j
/Lotus/:j
/MIS Anal/:j
/MIS Direct/:j
/MIS Manage/:j
/MS Windows/:j
/MUMPS/:j
/Mac Expert/:j
/Mac Imaging/:j
/Mac Prepress/:j
/Mac Video/:j
/Macintosh/:j
/Mainframe/:j
/Maintenance/:j
/Manual Writer/:j
/Manufactur/:j
/Market Devel/:j
/Marketing/:j
/Massachusetts/:j
/Measurement/:j
/Mech. Eng/:j
/Mechanical/:j
/Medical Director/:j
/Medical.Imagin/:j
/Microtechnology/:j
/Mixed Signal/:j
/Modeling Analyst/:j
/Molecular/:j
/Mosaic/:j
/Motif/:j
/Multimedia/:j
/NYC/:j
/NeXT/:j
/Network Admin/:j
/Network Anal/:j
/Network Arch/:j
/Network Devel/:j
/Network Eng/:j
/North Carolina/:j
/Novell/:j
/Nurse/:j
/OS2/:j
/OS400/:j
/OSI Devel/:j
/Object Orient/:j
/Occupational Therap/:j
/Office Manager/:j
/OpenLook/:j
/Operating System/:j
/Operator/:j
/Optical Eng/:j
/PC Admin/:j
/PC Coord/:j
/PC Support/:j
/PCB/:j
/Packaging/:j
/Payroll/:j
/PeopleSoft/:j
/Personnel Manager/:j
/Pharmac/:j
/Photographer/:j
/Physical Therap/:j
/Physician/:j
/Plastics Eng/:j
/Porting Position/:j
/Postdoc/:j
/Postscript/:j
/Power Generat/:j
/Power Supply/:j
/PowerBuilder/:j
/PowerSoft/:j
/Pressman/:j
/Process Deve/:j
/Process Eng/:j
/Prod Mgr/:j
/Product Engineer/:j
/Product Manage/:j
/Product Support/:j
/Production/:j
/Professor/:j
/Programmer/:j
/Psycholog/:j
/Purchaser/:j
/Purchasing/:j
/QA/:j
/Quality Assur/:j
/Quality Control/:j
/Quality Eng/:j
/Quality Manage/:j
/Quality Prof/:j
/RDBMS/:j
/RF Circuit/:j
/RF Design/:j
/RF Eng/:j
/RF Hardware Design/:j
/RN.Surg Care/:j
/RPG/:j
/RS.6000/:j
/Radio Engineer/:j
/Real Time/:j
/Refrigeration/:j
/Regulatory/:j
/Research Assist/:j
/Research Associate/:j
/Research Scientist/:j
/Resource Coordinator/:j
/Routing expert/:j
/SGML/:j
/SMALLTALK/:j
/Sales/:j
/Scientist/:j
/Self Employ/:j
/Senior Level Manager/:j
/Server Head Honcho/:j
/Servo/:j
/SmallTalk/:j
/Software/:j
/South Florida/:j
/Statistic/:j
/Structural Engineer/:j
/Summer CoOp/:j
/Summer Intern/:j
/Summer Job/:j
/Support/:j
/Surgeon/:j
/Sybase/:j
/System Admin/:j
/System Analyst/:j
/System Eng/:j
/System Manage/:j
/System Oper/:j
/Systems Eng/:j
/Systems Integration/:j
/Systems Test/:j
/Systems Writer/:j
/TV News/:j
/Teacher/:j
/Teaching/:j
/Technical Document/:j
/Technical Services/:j
/Technical Support/:j
/Technical Writ/:j
/Technical support/:j
/Technician/:j
/Technology Anal/:j
/Technology Consu/:j
/Telecom/:j
/Teleconferencing/:j
/Telephony/:j
/Tenure/:j
/Test Eng/:j
/Traffic.Highway Eng/:j
/Trainer/:j
/Training/:j
/Translator/:j
/Unix/:j
/VHDL Tester/:j
/VLSI Module Design/:j
/VMS/:j
/Visual BASIC/:j
/Visual Designers/:j
/WAN Datacomm/:j
/Washington DC/:j
/Water Treatment/:j
/Windows Devel/:j
/Windows Driver/:j
/Windows Guru/:j
/Windows NT/:j
/Windows SDK/:j
/X.25/:j
/X.MOTIF/:j
/X.Windows/:j
Paul Schauble
>p...@world.std.com (Peter C McCluskey):
>> [regarding recruiters]
>> I doubt that any solution could be enforced, even with robomoderation.
>
> No, it wouldn't be hard. I don't think we need to eliminate recruiters
>by any means, but merely tag them. Some folks use recruiters as a resource,
>some folks don't want to deal with them.
> Tagging via robomoderation is fairly simple - first, ask recruiters to
>self-tag, according to whatever format we decide on. This could be work in
>the subject line or in the keywords line. For those recruiters who don't
>self-tag, the robomoderator could check the poster's address and tag if it
>exists on a list of recruiters. The list could be expanded as needed. Yes,
>some will slip through, but this would tag the vast majority.
I think required keywords in the subject line is a good way to go, with
a robomoderator requiring the proper format and returning posts that
don't meet it. I disagree with an earlier post that said that returning
posts is a disservice to a job hunter. The current mess is a disservice
to the job hunter.
> Our primary goal is not to _filter_ posts, but to _classify_ them.
>Eugene and I came to the conclusion that it's very reasonable to expect the
>job-seekers to know how to use KILL files to aid their job search. In
>addition, there's the assumption that the technical expertise of the
>*posters* is very low (HR depts.).
> What do folks think, by the way, about using the keywords: line? I
>think that robomoderation could make good use of this header line.
Which newsreaders can kill/select on the keywords line? If nn can, I
don't know how to do it. Anyone care to enlighten me?
++PLS
Eugene N. Miya
Working with software and security too long.
"I must go now. Somewhere, there is some DOS happening ..." <thump,
thump, thump> --Crispin Cowan
In article <30nenr$q...@crl.crl.com> p...@crl.com (Paul Schauble) writes:
>Which newsreaders can kill/select on the keywords line? If nn can, I
>don't know how to do it. Anyone care to enlighten me?
REDRUM. REDRUM. REDRUM. REDRUM.
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull boy.
...
Newsgroups: ca.general,ba.general
Subject: [l/m 4/25/94] Kill files . . . with extreme prejudice
Summary:
References:
Sender:
Reply-To: eug...@amelia.nas.nasa.gov (Eugene N. Miya)
Followup-To: poster
Distribution: ca
Organization: NASA Ames Research Center, Moffett Field, CA
Keywords:
Panel 20
Table of Contents of this Chain
20 Killfiles (with extreme prejudice) <This panel>
24 Canceling posted news articles
28 News quiz
1 Reminders on use of the *.general news.groups
8 General Help Reading News
12 Posting headers and cross-posting
16 Distribution Fields
Kill files:
or how to stop reading
1) people you don't like, or
2) dated FAQ postings you've already read, or
3) reading subjects you think dull, or
4) ...
Not all systems have Kill files. I personally wish this could be more
general, but I've failed trying to find better strategies, maybe you can write
a better one? This example uses the rn news reader, but similar commands
can be found on other systems. Ask your News admin. Notably lacking is one
for Notefile systems. While the Kill command exists, it is crude with
problems, and a best strategy or style is needed to surgerically remove
unwanted messages, messengers, or 'bills.'
The best strategy appears to be
1) creat a Kill file
2) edit it
Select a message/topic/person to terminate with extreme prejudice,
The 'K' command creates a KILL file in your News directory structure which
mimics the News hierarchy (e.g., News/ba/general); it looks like:
<BOF>
THRU message#
/search strings of articles to junk/j
<EOF>
THRU is just a pointer: all messages checked to that point. Killing
starts at that message. The search string is usually a portion of the
Subject: field. Next edit using
^K (control-K). This places one in the editor (setenv using the EDITOR
environment variable, vi is default). Here you edit
the search string for messages you wish to junk. There is a search time
cost associated prior to actually reading news, your key is editing this
search string. You can use '*' as the wildcard (glob, or Kleene star)
character. You can restrict the search to just message Headers or
search a whole message. Let's just restrict Headers:, add an 'h' before
the 'j' for junk:
/:fromstring/h:j or
/:subjectstring/h:j
Note the ':' in the string anchors the search to specific fields in the
header body. Collect and keep or delete j-lines.
So for instance, if you want to stop reading automated posting
FAQ messages, you can K on one
/: Welcome to*/h:j # for many groups
/: [l/m 4.25.1994] Kill files*/h:j # for this message
/: *obnoxious*/h:j # stop reading anything by obnoxious
/: *eugene@*/h:j # stop reading anything by me in that group
Disadvantages: as said by more than one person: sometimes you want to
resume reading some one or thing. This is where the l/m comes into the
search field/ it allows you to stay current but avoid old messages.
Otherwise, you must take some time to edit Kill files.
Exercises for advanced readers:
1) Write a Kill file regular expression to get rid of most followup posts
(i.e., show only original posts).
2) Write a Kill file regular expression to get rid of cross-posted articles.
2a) Suppose you wanted to control the amount of cross-posting (like three
cross posts is okay, but four or more is not), explain how.
3)
This is the end.
-- Jim Morrison
SEE ALSO
kill(1).
Here's the information on Gnus. Edit as you wish.
(M-x is Meta-x or ESC <x>)
`M-k'
Edit a local KILL file applied to the current newsgroup
(`gnus-Subject-edit-local-kill'). *Note KILL File::, for more
information.
`M-K'
Edit a global KILL file applied to all newsgroups
(`gnus-Subject-edit-local-kill'). *Note KILL File::, for more
information.
KILL File
*********
The purpose of a KILL file and its usage are described here.
* Menu:
* What KILL Files Do:: An introduction to a KILL file.
* Making a KILL File:: How to make a KILL file.
* Editing KILL Files:: How to edit KILL files.
* Example of a KILL File:: An example of a KILL file.
* Background Kills:: Background kill processing.
* Advanced Kills:: Advanced kill processing.
What KILL Files Do
==================
A "KILL" file contains lisp expressions to be applied to a selected
newsgroup. The purpose is to mark articles as read on the basis of some
set of regexps.
There are two kinds of KILL files, global and local. A global KILL
file is applied to every newsgroup, and a local KILL file to a specified
newsgroup. Since a global KILL file is applied to every newsgroup, for
better performance use a local one.
Making a KILL File
==================
A KILL file can contain any kind of Emacs lisp expressions expected to
be evaluated in the Subject buffer. Writing lisp programs for this
purpose is not easy because the internal working of GNUS must be
well-known. For this reason, GNUS provides a general function which
does this easily for non-lisp programmers.
(gnus-kill FIELD REGEXP &optional COMMAND ALL)
The `gnus-kill' function executes commands available in Subject Mode by
their key sequences. `gnus-kill' must be called with FIELD, REGEXP, and
optional COMMAND and ALL. FIELD is a string representing the header
field or an empty string. If FIELD is an empty string, the entire
article body is searched for. REGEXP is a string which is compared with
FIELD value. COMMAND is a string representing a valid key sequence in
Subject Mode or a lisp expression. COMMAND is default to
`(gnus-Subject-mark-as-read nil "X")'. Make sure that COMMAND is
executed in the Subject buffer. If the second optional argument ALL is
non-`nil', the COMMAND is applied to articles which are already marked
as read or unread. Articles which are marked are skipped over by
default.
For example, if you want to mark articles of which subjects contain
the string `AI' as read, a possible KILL file may look like:
(gnus-kill "Subject" "AI")
If you want to mark articles with `D' instead of `X', you can use the
following expression:
(gnus-kill "Subject" "AI" "d")
In this example it is assumed that the command
`gnus-Subject-mark-as-read-forward' is assigned to `d' in Subject Mode.
It is possible to delete unnecessary headers which are marked with `X'
in a KILL file by using the function `gnus-expunge' as follows:
(gnus-expunge "X")
If the Subject buffer is empty after applying KILL files, GNUS will
exit the selected newsgroup normally. If headers which are marked with
`D' are deleted in a KILL file, it is impossible to read articles which
are marked as read in the previous GNUS sessions. Marks other than `D'
should be used for articles which should really be deleted.
All sorts of searches in Subject Mode normally ignore the case of the
text they are searching through. If you do not want to ignore the case,
set the variable `case-fold-search' to `nil'.
Editing KILL Files
==================
The command `M-K' in Subject Mode and Group Mode
(`gnus-Subject-edit-global-kill' and `gnus-Group-edit-global-kill') pops
up an Emacs buffer for editing a global KILL file. A global KILL file
is created in the directory specified by the variable
`gnus-article-save-directory' (default to `~/News'), and its file name
is specified by the variable `gnus-kill-file-name' (default to `KILL').
The command `M-k' in Subject Mode and Group Mode
(`gnus-Subject-edit-local-kill' and `gnus-Group-edit-local-kill') pops
up an Emacs buffer for editing a local KILL file. A local KILL file for
a newsgroup NEWS.GROUP is created as `NEWS.GROUP.KILL' in the directory
specified by the variable `gnus-article-save-directory' if the variable
`gnus-use-long-file-name' is non-`nil'. Otherwise, if the variable
`gnus-use-long-file-name' is `nil', the file is created as
`NEWS/GROUP/KILL' under the same directory.
The major mode of these buffers is "KILL-File Mode". This mode is
specialized for editing Emacs lisp programs the same as Emacs-Lisp Mode.
In addition to Emacs-Lisp Mode, the following commands are available:
`C-c C-k C-s'
Insert a template of a kill command on subject
(`gnus-Kill-file-kill-by-subject').
`C-c C-k C-a'
Insert a template of a kill command on author
(`gnus-Kill-file-kill-by-author').
`C-c C-a'
Apply current buffer being edited to selected newsgroup
(`gnus-Kill-file-apply-buffer').
`C-c C-e'
Apply sexp before point in current buffer to selected newsgroup
(`gnus-Kill-file-apply-last-sexp').
`C-c C-c'
Save the KILL file and then return to the previous buffer
(`gnus-Kill-file-exit').
`C-c C-i'
Read Info on KILL file (`gnus-Info-find-node'). *Note Texinfo
Manual::, to prepare an Info file of GNUS.
If KILL-File Mode is invoked from Subject Mode by the command
`gnus-Subject-edit-local-kill' or `gnus-Subject-edit-global-kill', the
commands `C-c C-k C-s' and `C-c C-k C-a'
(`gnus-Kill-file-kill-by-subject' and `gnus-Kill-file-kill-by-author')
insert a kill command on the subject and author of an article where the
point is on, respectively. Otherwise, a template of a kill command is
inserted.
The commands `C-c C-a' and `C-c C-e' (`gnus-Kill-file-apply-buffer'
and `gnus-Kill-file-apply-last-sexp') can be used to test kill commands
being edited in current buffer. The kill commands are applied to
current newsgroup.
Example of a KILL File
======================
The following is an example of a local KILL file for newsgroup
`control'. This is currently being used by the author.
;; Apply to the newsgroup `control' if the NNTP server is flab.
(if (string-equal gnus-nntp-server "flab")
(progn
(gnus-kill "Subject" "ihave flab\\|sendme")
(gnus-kill "Subject" "cancel\\|newgroup\\|rmgroup" "d")
(gnus-expunge "X")))
Background Kill Processing
==========================
Kill processing may take long time. If it becomes terribly
frustrating, try background kill processing using the following shell
command:
emacs -batch -l gnus -f gnus-batch-kill NEWSGROUPS
where NEWSGROUPS argument is newsgroup names separated by either white
spaces or a comma. `!' preceding a newsgroup name means negation, and
`all' matches anything else. These interpretations are the same as the
options line of the startup file (*Note Startup File::).
Advanced Kill Processing
========================
Internally, applying kills means to run the hook
`gnus-Apply-kill-hook'. It is called after the Subject buffer is
prepared for a selected newsgroup. The default hook is the function
`gnus-apply-kill-file' which loads a global KILL file and a local KILL
file in this order. A different style of the kill processing can be
implemented by customizing this hook.
For example, if you think a global KILL file is unnecessary, you can
use the following hook which applies only a local KILL file. This
change can save the time for checking the existence of a global KILL
file.
(setq gnus-Apply-kill-hook
'(lambda ()
;; Apply a local KILL file.
(load (gnus-newsgroup-kill-file gnus-newsgroup-name) t nil t)))
On the contrary, the following example enables only a global KILL
file.
(setq gnus-Apply-kill-hook
'(lambda ()
;; Apply a global KILL file.
(load (gnus-newsgroup-kill-file nil) t nil t)))
Here is an advanced example that drastically reduces the time for
applying KILL files. This hook does the kill processing directly
without loading the KILL files.
(setq gnus-Apply-kill-hook
'(lambda ()
;; Apply to the newsgroup `control'
;; if the NNTP server is flab.
(and (string-equal gnus-nntp-server "flab")
(string-equal gnus-newsgroup-name "control")
(progn
(gnus-kill "Subject" "ihave flab\\|sendme")
(gnus-kill "Subject" "cancel\\|newgroup\\|rmgroup" "d")
(gnus-expunge "X")))))
Expire-kill
===========
I thought you'd want to mention Ben Liblit's
wonderful expire-kill package that's available from the archives at
archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/misc/expire-kill.el.Z
Expire-kill is an emacs add-on that automatically performs an otherwise
nasty chore: periodic cleanup of your killfile. Under many (most?)
newsreaders, eventually your killfiles will get Ugly Regexp Buildup(tm)
from threads long dead; in order to improve newsreader performance, you
must clean out obsolete thread kills. Expire-kill attaches a timestamp
to each thread kill; every time that kill is invoked, the timestamp is
updated. If a expire-kill'd thread kill has a timestamp older than the
maximum allowable age, the thread kill is removed. I don't know anyone
who uses GNUS that doesn't use this wonderful utility (but that may just
be because I don't know many people who use GNUS!).
maus
>
>Which newsreaders can kill/select on the keywords line? If nn can, I
>don't know how to do it. Anyone care to enlighten me?
I don't know nn, but s[t[rn]] can do it with the h modifier to search. This
causes it to search the entire header for the word. I _think_ there's a new
feature of trn that can look at any one line in the header as well.
--
Ma...@io.com
The great thing about experience is knowing when to cringe.