[comp.sources.d] How can a moderator take a vacation?

bill@twwells.uucp (T. William Wells) (11/22/88)

In article <7681@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:
: In the referenced message, bill@twwells.UUCP (T. William Wells) wrote:
: >Mr. Poskanzer,
: >Shut your yap.  We moderate newsgroups out of generosity, spending
: >time and money to so, because we believe that what we are doing is a
: >good thing.  You have no business badmouthing one of us because he
: >isn't doing it just the way you'd like.
:
: I write free software out of generosity, spending time and money to
: do so, because I believe that what I am doing is a good thing.  But
: when I try to get it distributed, what do I find?  The moderated sources
: groups are dead for months at a time, and the unmoderated sources group
: reaches only half the net.  I'm not the only one who has pointed this out.
: I'm not the only one who objects.

Well, I know there is a problem. I've noticed that the moderated
groups tend to have their on and off periods. And constructive
suggestions for dealing with this are needed.

Not only that, but sooner or later, I'm going to want to take a
vacation (they'll never believe me at work :-), and I'd certainly
like to have some way to keep comp.archives from dying while I am
gone. So I view this as something worth thinking about.

: >Suggestions are welcome, personal remarks are not.
:
: Yes, suggestions are welcome, but holier-than-thou chest-beating is not.
: And by the way, the message you replied to included a suggestion.  Perhaps
: you were too busy yapping to notice and comment on it.  It is certainly
: clear that the moderators are uninterested in making any suggestions of
: their own.

Had you stopped right after the suggestion, I'd have been a little
irritated at the sarcasm displayed in the earlier part of the
posting, but I'd have been more than happy to talk about constructive
solutions to the problem. But then you went off and insulted the
person you were talking to.  That is not the mark of a person who is
trying to solve a problem, and so I didn't see any reason to talk
about your proposal.

---

Here's your chance. Since I would like to see a discussion about
this, I'll repost your suggestion and make my comments. And hope that
your replies don't contain more insults.

: Anyway, I was thinking more along the lines of a primary moderator and
: a backup moderator.  Both would receive the postings, but the backup would
: normally throw them out.  However, if the primary disappears for a while,
: or perhaps even goes on a real vacation, the backup would be able to take
: over with minimal fuss.

This could be made to work. However, there are several things that
need to be dealt with for it to. The first is that the backbone sites
have to have the newsgroups aliased to both names. This ought not to
be anything more than an administrative problem. The second has to do
with communication. Some method needs to be established so that the
backup moderator knows when to pick up the traces. Again, not too
much of a problem, just needs setting up the procedures.  There is
also the extra mail bandwidth. This can be serious when the newsgroup
deals with large things, as the source and binary newsgroups often do.
The main problem with this method is that the alternate moderator
can't get at messages related to the newsgroup that are sent to the
main moderator's personal account. I get quite a few of these, and I
don't suppose that I am unique.  I can't think of any scheme that
doesn't require explicit handing-off by the moderator that gets this
mail to the alternate moderator.

There is another, simpler, method: just have the moderator forward
his mail to the alternate moderator when he goes on vacation. This
has several drawbacks. First, if the moderator is also his system
administrator (as is the case with comp.archives), there is nothing
guaranteeing that his system will stay up while he is on vacation.
Second, there is an additional delay for the forwarded mail.  Third,
it does nothing for the case where the moderator "disappears", after
things like accidents, etc. And, of course, it doesn't solve the
problem of people who send mail to the moderator's personal account
(though the moderator can forward anything in his queue when he goes
on vacation).

Any comments?

---
Bill
{uunet|novavax}!proxftl!twwells!bill

ncoverby@ndsuvax.UUCP (Glen Overby) (11/22/88)

In article <200@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:

[long flamage deleted for sanity]

>Any comments?

Depending on how long the moderator is going on vacation and how long
is outgoing queue is, it might be very possible to set up "at" jobs to
automagicaly post the stuff daily.  It sounds like Rich $alz does this anyway
(I gather that from him making a remark about writing "at" jobs in an INF
posting a while back).

Most of the major dry spells I've seen haven't been due to a moderator taking
a vacation, but rather his system getting messed up (ncoast did this a while
back) or just plain being too busy at work to tend to the group for a short time.
There is little that can be done about systems crashing; we live with that
all the time anyway.  In the latter case, the moderator generally gives up
the reigns after a while.

Dry spells aren't all that bad, either.  It gives you time to port the stuff
to your machine that didn't run on it in the first place!

I guess as a parting statement, I'll say don't bittch about the service that
these guys give us; I don't know of ONE of them thats being paid to moderate
a group.  Or are you volunteering to take over?

Glen Overby
ncoverby@plains.nodak.edu       uunet!ndsuvax!ncoverby
ncoverby@ndsuvax (Bitnet)

lee@uhccux.uhcc.hawaii.edu (Greg Lee) (11/22/88)

Someone suggested in the course of this discussion that moderators
announce prospective vacations.  I'll second that.  Some already do
this.  It would lessen the need for a system of multiple moderators.

		Greg, lee@uhccux.uhcc.hawaii.edu

dmt@mtunb.ATT.COM (Dave Tutelman) (11/22/88)

Opening disclaimer:  I really do appreciate what the moderators do
for the source and binaries groups:
   -	Reduce clutter by redirecting non-program submissions to
	the .d groups.
   -	Repackage for uniformity.
   -	Some do test submissions, though I suspect this is rare.
   -	... (are there others I'm overlooking?) ...
All these functions are important conveniences.  They save the readers
much time and save the net a certain amount of bandwidth (perhaps not
much; not much of the stuff gets killed rather than redirected?).

HOWEVER, it IS a convenience and not a necessity.  We need to evaluate
the relative cost of short UNMODERATED periods of an otherwise
moderated group.  (The suggestion of automatic posting, perhaps with
an "at" script, was made by someone else; sorry I can't credit him/her
properly, but I've lost the posting.)  Here's my contribution to the
debate:

ADVANTAGES:
   -	Programs would be posted shortly after their announcement in
	related groups.  (I've announced programs in, say, rec.bicycles
	or comp.sys.ibm.pc, and had to deal with mail for
	a week or two asking why the reader hadn't seen it yet.)
   -	Smoother flow of postings, without "dry spells".
   -	We'd have more appreciation of the moderator on his/her return.

DISADVANTAGES:
   -	(Perhaps biggest problem) Programs would probably be posted
	whose format is in conflict with what's expected by
	somebody's archiving software.  (Is this fear real?)
   -	Without discipline, some discussion will appear in a program group.
   -	(Unlikely paranoia) Unprincipled posters will take the opportunity
	to post a trojan horse or virus.  (Only matters in those groups
	where the moderator does extensive testing.  Do such groups
	exist?)

Am I naive?  What other pros and cons are there?

+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ			|
|    Logical -  ...att!mtunb!dmt				|
|    Audible -  (201) 576 2442					|
+---------------------------------------------------------------+

ward@cfa.harvard.EDU (Steve Ward) (11/22/88)

Mr. Wells and the other net moderators are to be commended, not
"slimed."

Rhetorical question:  How many of the quick-to-complain-and-insult-via-
                      intercontinental-public-netnews have actually sent
                      personal, non-insulting, non-inflammatory, sincere
                      let's-discuss-it-as-rational-beings private email
                      to any of the moderators in question?

And I don't mean sending "quick lip shot from the hip" type of mail that
so routinely gets international airing in public.  What I mean, is a
sincere, diplomatic inquiry to open a dialogue for what is perceived to
be a problem on the part of the mail sender, entreating the moderator
to engage in a personable, two-way conversation aimed at developing
solutions to the problem.  I also don't mean to imply that
"brown-nosing" is required, but since one person's problem is another
person's solution, and civility will keep the focus on the real issues,
just plain being nice is in order.

I suspect that there has been close to zero legitimate direct dialogue,
and to the extent that it has happened, it is all probably
post "public sliming."

A (apparently not in vogue) minor suggestion:  talk personally,
privately, sincerely, and with civility with the principals before
having a public knee-jerk reaction.

Steve W.  ward@cfa.harvard.edu

cosell@bbn.com (Bernie Cosell) (11/22/88)

In article <1326@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes:
}We need to evaluate
}the relative cost of short UNMODERATED periods of an otherwise
}moderated group.

}ADVANTAGES:
}   -	Programs would be posted shortly after their announcement in
}	related groups.  (I've announced programs in, say, rec.bicycles
}	or comp.sys.ibm.pc, and had to deal with mail for
}	a week or two asking why the reader hadn't seen it yet.)

But you have to deal with this delay even if the moderator is around 
--- the reality is that there is always a variable, generally unpredicatble
by the poster, delay.  When you submit the
program you ought to ask the moderator to give you an estimated time of
publication.  Then delay your public announcement until the sources-date
comes close.

}DISADVANTAGES:
}   -	(Perhaps biggest problem) Programs would probably be posted
}	whose format is in conflict with what's expected by
}	somebody's archiving software.  (Is this fear real?)

Sure is.  Most sources groups these days sequentially number their postings,
collect them into "volumes", index the volumes and have various places that
provide archiving services.  Not to mention that it becomes possible to tell
if something gets bagged enroute (you get #35 and then #37 and you have a
clue that something's gone wrong).

}   -	Without discipline, some discussion will appear in a program group.
}   -	(Unlikely paranoia) Unprincipled posters will take the opportunity
}	to post a trojan horse or virus.  (Only matters in those groups
}	where the moderator does extensive testing.  Do such groups
}	exist?)

I think so... I'm quite sure that the moderators check that the program
compiles (at least on the moderator's system), that it unshars properly, has
a makefile, etc.

   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com

bgg@yarra.oz.au (Benjamin G. Golding) (11/23/88)

Why not have multiple moderators using a common method for generating
article id's on the postings that they send?  The posting would be
distributed normally but there will be two versions on the net having
different senders.  Identical id's would prevent the duplicate copies
being distributed any more than necessary.

The article id chosen would have to use some part of the sender's
message - this is the only thing that the multiple moderators have in
common.

	Ben.

bill@twwells.uucp (T. William Wells) (11/24/88)

In article <1826@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes:
: In article <200@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
: >Any comments?
:
: Depending on how long the moderator is going on vacation and how long
: is outgoing queue is, it might be very possible to set up "at" jobs to
: automagicaly post the stuff daily.

Well, that is much the same as making the group temporarily
unmoderated. This may or may not be a good thing.  For
comp.sources.stuff this doesn't help, as the postings should follow a
form which the moderator creates. Comp.archives, on the other hand,
contains both discussions and specially formatted postings; a mail
reflector, however implemented, only has to prevent resent postings
from looking like the specially formatted postings.  Other moderated
newsgroups are purely discussion groups, for them, this would be no
problem.

: I guess as a parting statement, I'll say don't bittch about the service that
: these guys give us; I don't know of ONE of them thats being paid to moderate
: a group.  Or are you volunteering to take over?

Ahhh, perhaps you don't realize that I *already* moderate a
newsgroup, comp.archives?

---
Bill
{uunet|novavax}!proxftl!twwells!bill

bill@twwells.uucp (T. William Wells) (11/24/88)

In article <1326@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes:
: HOWEVER, it IS a convenience and not a necessity.  We need to evaluate
: the relative cost of short UNMODERATED periods of an otherwise
: moderated group.
:
: DISADVANTAGES:
:    -  (Perhaps biggest problem) Programs would probably be posted
:       whose format is in conflict with what's expected by
:       somebody's archiving software.  (Is this fear real?)

Yes. For certain groups, there is a problem with sequencing:
comp.sources.stuff has these posting numbers, there is no guarantee
that posters will manage to get these right. This would make life
more than a little difficult for those who archive the newsgroups.

For comp.archives, the newsgroup I moderate, there are two kinds of
postings, which are distinguished by their subject lines. I could set
up a mail reflector for the discussion postings, and have the program
put aside the other postings, which are supposed to be specially
formatted.

It would be possible to set up a program that verifies the other
postings and posts them (or sends them back) after verification, but
this begins to get complicated.

:    -  Without discipline, some discussion will appear in a program group.

Some? :-) Seriously though, some discussion would have to take place
*somewhere*.  There may not always be an appropriate place. And any
newcomer is going to have to post some questions in the newsgroup
just to find out where the appropriate place is for the discussions.

:    -  (Unlikely paranoia) Unprincipled posters will take the opportunity
:       to post a trojan horse or virus.

This is a yes&no. It is trivial for anyone who wants to to post
bogusly to a moderated newsgroup; the practice of serializing the
postings makes this a little difficult, but certainly not impossible.

:                                         (Only matters in those groups
:       where the moderator does extensive testing.  Do such groups
:       exist?)

On the other hand, the moderators are in a position to determine
*who* submitted the code; this helps to discourage people from
submitting compromised code. Were I running a code newsgroup, I'd
check out the *person* who submitted any code that I couldn't verify
to be clean.

: Am I naive?  What other pros and cons are there?

Well, for me, the problem is that I couldn't set up a mail reflector
and be sure that it would continue while I was away.  I don't know if
any other moderators are also their system's administrator. If any
are, they are in the same boat as I am.

And if I didn't set up a mail reflector, the specially formatted
postings wouldn't get any verification. This would be a disaster,
something on the order of posting garbage to comp.mail.maps.

---
Bill
{uunet|novavax}!proxftl!twwells!bill

pokey@well.UUCP (Jef Poskanzer) (11/26/88)

In the referenced message, bill@twwells.UUCP (T. William Wells) wrote:
}In article <7681@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:
}: Anyway, I was thinking more along the lines of a primary moderator and
}: a backup moderator.  Both would receive the postings, but the backup would
}: normally throw them out.  However, if the primary disappears for a while,
}: or perhaps even goes on a real vacation, the backup would be able to take
}: over with minimal fuss.
}
}This could be made to work. However, there are several things that
}need to be dealt with for it to. The first is that the backbone sites
}have to have the newsgroups aliased to both names. This ought not to
}be anything more than an administrative problem.

Yes, this was too obvious for me to mention.

}                                                 The second has to do
}with communication. Some method needs to be established so that the
}backup moderator knows when to pick up the traces. Again, not too
}much of a problem, just needs setting up the procedures.

Yes, such procedures are easy to figure out and not particularly critical.
Since we are getting explicit here, how about this: if the backup moderator
doesn't see any postings in the group for a month, and checks an alternate
news-reading site to make sure it's not a local problem, and can't get in
touch with the primary moderator by PHONE (e-mail would be useless), then
the backup takes over and the primary becomes the backup.

What I meant by not particularly critical is that in the unlikely event
that both moderators think they are the primary (perhaps both the net and
the phone system got partitioned), recovery is trivial.  And it's also not
particularly critical that the backup take over instantly, since if he takes
over AT ALL the net will be better off than it is under the current system.

}                                                          There is
}also the extra mail bandwidth. This can be serious when the newsgroup
}deals with large things, as the source and binary newsgroups often do.

No, I can't see this being a serious issue.  We are talking about a few
kilobytes per day for just the machines along the mail paths, which will
be totally lost in the noise of the three MEGAbytes per day of news going
to every machine on the net.

}The main problem with this method is that the alternate moderator
}can't get at messages related to the newsgroup that are sent to the
}main moderator's personal account. I get quite a few of these, and I
}don't suppose that I am unique.  I can't think of any scheme that
}doesn't require explicit handing-off by the moderator that gets this
}mail to the alternate moderator.

Oh, nonsense.  That's what *-request aliases are for!

}There is another, simpler, method: just have the moderator forward
}his mail to the alternate moderator when he goes on vacation.

I am not worried about real vacations.  No one gives a hoot about postings
stopping for two or three weeks, especially if the moderator posts a note
first warning about the upcoming hiatus.  The problem is with the multi-month,
unplanned, unannounced, unexplained absences that I referred to as "vacations".
Apparently you didn't not realize I was using the term sarcastically.

Now the problem with your simpler method should be (once again) obvious:
it requires the moderator to take action when he about to disappear.  Since
the disappearance could be due to his machine failing, or a newsfeed of his
failing, or merely a sudden case of brain-lock, he does not know when he
is about to disappear, and so cannot take any action.  A more robust mechanism
is necessary.
---
Jef

             Jef Poskanzer   jef@rtsg.ee.lbl.gov   ...well!pokey
 "Good judgement comes from experience. Experience comes from bad judgement."
                                -- Jim Horning

how@milhow1.UUCP (Mike Howard) (11/26/88)

I have a hard time thinking of any case where a couple of week delay (or
a month for that matter) is really significant.  In cases where it actually
is a problem there are several alternatives to mucking around with the
moderation process: for example:
 - advertizing in unmoderated groups and e-mail
 - Federal Express
 - Ma Bell and the Post Office.

As a suggested answer to `How can a moderator take a vacation?':  just
like anyone else: save your money, decide where and when to go, tell
a few friends when you are leaving and when you'll be back (maybe), and
then take off.

Please keep up the tremedous service in moderating moderated groups.  You
guys have my permission to take vacations _any_time_ you want to.

BTW, I seem to remember that this discussion was started by a Mr. Poskanzer.
Is he the same guy who `modified' the GNU copyleft to read something like
   `... and if you use my stuff to make some money with, I
    want some of it ...' or words more or less to that effect?
If he isn't, I appologise in advance.

-- 
Mike Howard
uunet!milhow1!how

pokey@well.UUCP (Jef Poskanzer) (11/26/88)

In the referenced message, how@.UUCP (Mike Howard) wrote:
}BTW, I seem to remember that this discussion was started by a Mr. Poskanzer.
}Is he the same guy who `modified' the GNU copyleft to read something like
}   `... and if you use my stuff to make some money with, I
}    want some of it ...' or words more or less to that effect?
}If he isn't, I appologise in advance.

Don't you just love folks who "seem to remember" but actually DON'T?  Not
only have I never made any such modified copywhatever (the copyrite I use
is a very close copy of the one on the X window system sources), but I did
NOT start this discussion.  And even if I had done either or both of the
above, WHAT DIFFERENCE WOULD IT MAKE???  Ideas stand or fall on their own
merits DO THEY NOT???

Oh well, Mike obviously didn't mean any harm.  He's just a moron.  "Appology"
accepted.
---
Jef

             Jef Poskanzer   jef@rtsg.ee.lbl.gov   ...well!pokey
    "And then he went into his office, going mrmee, mrmee, mrmee, mrmee."

bill@twwells.uucp (T. William Wells) (11/27/88)

In article <7755@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:
: }                                                 The second has to do
: }with communication. Some method needs to be established so that the
: }backup moderator knows when to pick up the traces. Again, not too
: }much of a problem, just needs setting up the procedures.
:
: Yes, such procedures are easy to figure out and not particularly critical.
: Since we are getting explicit here, how about this: if the backup moderator
: doesn't see any postings in the group for a month, and checks an alternate
: news-reading site to make sure it's not a local problem, and can't get in
: touch with the primary moderator by PHONE (e-mail would be useless), then
: the backup takes over and the primary becomes the backup.

That's certainly workable, though maybe two weeks might be more
reasonable (depending on the group, of course).

: }The main problem with this method is that the alternate moderator
: }can't get at messages related to the newsgroup that are sent to the
: }main moderator's personal account. I get quite a few of these, and I
: }don't suppose that I am unique.  I can't think of any scheme that
: }doesn't require explicit handing-off by the moderator that gets this
: }mail to the alternate moderator.
:
: Oh, nonsense.  That's what *-request aliases are for!

You know that. I know that. But about 30% of the people sending to
comp.archives do it to my personal account.

Another half of the messages I get are replies to postings.  These
get sent to a specific mail address and the backbone sites never get
the chance to redirect them.

: Now the problem with your simpler method should be (once again) obvious:
: it requires the moderator to take action when he about to disappear.  Since
: the disappearance could be due to his machine failing, or a newsfeed of his
: failing, or merely a sudden case of brain-lock, he does not know when he
: is about to disappear, and so cannot take any action.  A more robust mechanism
: is necessary.

Well, "necessary" isn't the word I'd use. Call it "desirable".  That
puts things in perspective. No one who gets things from the moderated
newsgroups appreciates it when those newsgroups dry up.  One of the
issues at hand is whether this inconvenience justifies having a backup
moderator.  This is certainly not an open-and-shut question.

Might I suggest that this "should" should be dealt with in the way
that all other questions of this type are dealt with?

Yes, the vote!

In other words, you seem to feel that comp.sources.unix is not
adequately moderated. So, go over to news.groups, propose that "x"
(you get to find "x") be appointed alternate moderator of
comp.sources.unix, and see if you can get the 100 vote spread for
approval.  If you manage to get the votes, I'm sure that the current
moderator will figure out some method of using the backup.

---
Bill
{uunet|novavax}!proxftl!twwells!bill

allbery@ncoast.UUCP (Brandon S. Allbery) (11/28/88)

As quoted from <200@twwells.uucp> by bill@twwells.uucp (T. William Wells):
+---------------
| There is another, simpler, method: just have the moderator forward
| his mail to the alternate moderator when he goes on vacation. This
| has several drawbacks. First, if the moderator is also his system
| administrator (as is the case with comp.archives), there is nothing
| guaranteeing that his system will stay up while he is on vacation.
| Second, there is an additional delay for the forwarded mail.  Third,
| it does nothing for the case where the moderator "disappears", after
| things like accidents, etc. And, of course, it doesn't solve the
| problem of people who send mail to the moderator's personal account
| (though the moderator can forward anything in his queue when he goes
| on vacation).
+---------------

I've had an arrangement whereby if I disappear (accident, vacation, whatever)
and it'll be longer than a few days, someone else on ncoast takes over
comp.sources.misc for the duration.  It's largely automated anyway; the
submissions may not be as "clean" as when I'm doing it (experience counts
for much) but they would go out.  (In the case of an accident:  if I'm not
on for two days in a row it's a safe assumption that I'm out of commission.)
The main drawback, again, is all the submissions that land in my mailbox
despite repeated pleas to not do that.

The main PROBLEM with this is what made me initiate the move to uunet in the
first place:  ncoast is not, in my opinion, stable enough for a moderated
newsgroup to be housed on it.  Think back to early September, when
news.sysadmin was suddenly flooded with all the "where is ncoast?" postings
because it took us a week to get a replacement CPU board.  Unfortunately, I
can't arrange to have someone else on UUNET handle comp.sources.misc, and I
suspect Rick Adams would take a dim view of my giving someone else my
password on UUNET to handle it for me a' la the current arrangement.  And
Rich Salz already has enough on his hands (it's his "vacation" that started
this thread; you think he has time to handle comp.sources.misc when he
doesn't have time enough to do .unix?)

Perhaps a solution-- Have *all* the moderated newsgroups be housed on UUNET,
with special accounts for them.  The moderator(s) do all their work on UUNET
-- and if the primary moderator disappears, the backup moderator (who has
been logging in daily, or weekly, or whatever to check on the newsgroup's
status) will pick up the slack until the primary announces his return via
mail on UUNET.  I will note that comp.sources.unix and (soon)
comp.sources.misc will already be in a position to do this; I don't know
about Rich Salz, but *my* account on UUNET will not be used for personal
business, so I have no qualms about having people other than myself reading
my mailbox there.  (That is not intended to be any sort of flame or etc. on
Rich Salz, I don't know the intent of his uunet account.  I do get the
impression that BBN is a bit more restrictive than ncoast in what users can
do re: the Usenet, so it would be understandable if Rich's account is a bit
more than just a comp.sources.unix moderator's account.)

This would keep central control over the archive-numbers, which *are* quite
often used by automated archiving systems, while allowing for smooth
transfer of control not only when a moderator disappears for a short time
but *also* when a moderator quits or is replaced.  (Recall the mess when
I had to give up comp.binaries.ibm.pc for lack of time.)  The big minus is
that everything depends on UUNET being functional; on the other hand, it
could be argued that if UUNET goes down, the whole Usenet will be affected
anyway, so it's no more of a problem than before.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery@hal.cwru.edu
allberyb@skybridge.sdi.cwru.edu	      <ALSO>		   allbery@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.

bill@twwells.uucp (T. William Wells) (11/29/88)

In article <13186@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
: The main drawback, again, is all the submissions that land in my mailbox
: despite repeated pleas to not do that.

Oh dear. If you haven't been able to solve this problem with appeals
to reason, I don't imagine that I'll have any better luck.

If it gets to be a real problem, I might make it a practice to bounce
stuff coming to my personal account. It wouldn't be nice, but it
would be a solution.

: Perhaps a solution-- Have *all* the moderated newsgroups be housed on UUNET,
: with special accounts for them.  The moderator(s) do all their work on UUNET
: -- and if the primary moderator disappears, the backup moderator (who has
: been logging in daily, or weekly, or whatever to check on the newsgroup's
: status) will pick up the slack until the primary announces his return via
: mail on UUNET.

This is a good idea, and of course, UUNET, while the obvious choice,
doesn't have to be the only system where moderators work from. Any
reasonably stable system where this would be allowed would do.

And the backup moderator doesn't have to log on till a problem
develops; the moderator's account could have a cron job which checks
to see if the account has been used in a week or whatever.  If it
hasn't, the job could send a message to the backup moderator and post
a message to the newsgroup.

---
Bill
{uunet|novavax}!proxftl!twwells!bill

allbery@ncoast.UUCP (Brandon S. Allbery) (11/29/88)

As quoted from <32608@bbn.COM> by cosell@bbn.com (Bernie Cosell):
+---------------
| In article <1326@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes:
| }We need to evaluate
| }the relative cost of short UNMODERATED periods of an otherwise
| }moderated group.
| 
| }ADVANTAGES:
| }   -	Programs would be posted shortly after their announcement in
| }	related groups.  (I've announced programs in, say, rec.bicycles
| }	or comp.sys.ibm.pc, and had to deal with mail for
| }	a week or two asking why the reader hadn't seen it yet.)
| 
| But you have to deal with this delay even if the moderator is around 
| --- the reality is that there is always a variable, generally unpredicatble
| by the poster, delay.  When you submit the
| program you ought to ask the moderator to give you an estimated time of
| publication.  Then delay your public announcement until the sources-date
| comes close.
+---------------

As mentioned in the Welcome! posting (due out again in a few days), if you
send me the public accouncement I'll send it out at the same time as the
posting.  (Of course, the fact that ncoast's news admin insists on blocking
our receipt of certain newsgroups via rmgroup makes this difficult at
times.  One reason why I'm trying to move to UUNET.)

+---------------
| }DISADVANTAGES:
| }   -	(Perhaps biggest problem) Programs would probably be posted
| }	whose format is in conflict with what's expected by
| }	somebody's archiving software.  (Is this fear real?)
| 
| Sure is.  Most sources groups these days sequentially number their postings,
| collect them into "volumes", index the volumes and have various places that
| provide archiving services.  Not to mention that it becomes possible to tell
| if something gets bagged enroute (you get #35 and then #37 and you have a
| clue that something's gone wrong).
+---------------

It will be remembered that comp.sources.misc underwent a "catastrophic"
change of format in order to work with automated archivers.  It may *not* be
well known that I've had to tweak the format twice since then to make it
work with some archivers.  Did you think we did this for kicks?

+---------------
| }   -	(Unlikely paranoia) Unprincipled posters will take the opportunity
| }	to post a trojan horse or virus.  (Only matters in those groups
| }	where the moderator does extensive testing.  Do such groups
| }	exist?)
| 
| I think so... I'm quite sure that the moderators check that the program
| compiles (at least on the moderator's system), that it unshars properly, has
| a makefile, etc.
+---------------

Most do.  I don't, originally because it was preferred that I get stuff out
*fast* with minimal moderation baggage, and now because ncoast just plain
won't {compile|run} most of the submissions I get.  (And those that *do* run
have problems on systems *other* than ncoast.  Witness pwgen.  Sigh.)  Yet
another reson for the move.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery@hal.cwru.edu
allberyb@skybridge.sdi.cwru.edu	      <ALSO>		   allbery@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.

mju@m-net.UUCP (Marc Unangst) (11/30/88)

Re: Backup moderators that normally throw newsgroup-related mail away,
except when primary moderator is on vacation.

This could be implimented with aliases.  The moderator for comp.sources.unix
could be known only as unix-sources@foo.bar.bat.  On foo.bar.bat, the
id unix-sources is aliased to whatever the current moderator's id is.
Normally, this is the primary moderator.  However, when he/she goes on
vacation, they change the alias to that of the backup moderator.  This
alias doesn't have to be defined on the moderator's machine; it could be
on uunet or wherever else.  Just make sure that all mail to
unix-sources@foo.bar.bat goes through the machine with the alias.  This
way, the routing to the current moderator remains constant all the time.
Users don't even know that he's on vacation.

-- 
"Don't find a fault. | Marc Unangst
Find a remedy."      | UUCP: mju@m-net.ann-arbor.mi.us
  -Henry Ford        | UUCP path: ...!uunet!umix!m-net!mju
---------------------+ Internet: mju%m-net@umix.cc.umich.edu

allbery@ncoast.UUCP (Brandon S. Allbery) (12/02/88)

As quoted from <7755@well.UUCP> by pokey@well.UUCP (Jef Poskanzer):
+---------------
| In the referenced message, bill@twwells.UUCP (T. William Wells) wrote:
| }In article <7681@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:
| }The main problem with this method is that the alternate moderator
| }can't get at messages related to the newsgroup that are sent to the
| }main moderator's personal account. I get quite a few of these, and I
| }don't suppose that I am unique.  I can't think of any scheme that
| }doesn't require explicit handing-off by the moderator that gets this
| }mail to the alternate moderator.
| 
| Oh, nonsense.  That's what *-request aliases are for!
+---------------

We (Usenet moderators and, before us, mailing list moderators on Usenet and
ARPAnet) have been trying to get people to use the correct aliases for
YEARS.  This does not stop people from mailing their sources to ncoast!allbery.
And as long as they do so, no automatic moderator-switching scheme will work.

+---------------
| Apparently you didn't not realize I was using the term sarcastically.
+---------------

Apparently you didn't realize that computers don't transmit sarcasm.  You
have to make it obvious or people will miss the point.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery@hal.cwru.edu
allberyb@skybridge.sdi.cwru.edu	      <ALSO>		   allbery@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.