One thing that's probably worth pointing out is the difficulty of actually
doing this in a "clean" fashion. An example will make this clear.
I use postfaq to submit all my FAQs. Some registered, and some unregistered
(perhaps they're new and unapproved, or perhaps they're not suitable
for registration - ie: they're in a local hierarchy, or, you're trying
to make a change to the Subject: line or something).
The simplest way to register one of the unregistered FAQs is simply to
add news.answers (FAQ still has no Approved line) to the Newsgroups:
line, which will force it to go off to news.answers moderators at the next
time postfaq wants to post it (or forcing it earlier). Given how picky
the guidelines are, this is the only reliable way to ensure that the
additional headers that postfaq adds are complete in the "submission",
and avoid costly mistakes in getting them wrong after it is registered.
[Ie: trying to do a manual inews -h with manually generated headers, and
then making sure that there's no screwups when postfaq generates them
automatically after the Approved: line is added.]
So, you've simply changed the Newsgroups: line, and postfaq continues
to robotically post it according to the established schedule. Since,
until the Approved line is added, postfaq has no way of telling that
the article is being mailed rather than posted, it continues on its
merry way generating new Message-ID and Supersedes headers.
Several problems arise:
- there is no clean way to ensure that the Supersedes headers generated
are consistent with what was actually posted. If, for example,
news.answers answered quickly, you will have ended up with the
FAQ as posted *before* submission not being superseded by the
FAQ posted *after* approval - the after-submission posting actually
tries to supersede what got emailed to news.answers (which doesn't
do anything of course). This is best case.
- due to the vagaries of news.answers latencies, postfaq posting
schedules, vacations and weekends, postfaq may end up trying to submit
the FAQ to news.answers several times, even if the Approval has
already been sent (this sound familiar Tom?? ;-) and thereby
making your work even more difficult.
A technique published in the news.answers FAQ and/or improvement to postfaq
would make things a lot easier. Perhaps modifying postfaq to notice that
there is no Approved lines and the Newsgroups: line has a *.answers group
in it would allow it to retain consistency with the Supersedes - ie:
reuse the previous Message-ID until the Approval appears. Or a specific
"postfaq -"submit_with_proper_headers,_but_no_control_file_update" invocation.
I may be missing something in the documentation, but, who has time to reread
everything every time anything happens?
} PS to moderators: evidently the section of the intro documents covering
} this stuff is still not clear enough.
It's clear that it's not clear enough. I *know* how *.answers moderation
and news works (the latter in intimate detail ;-), and even I have difficulty
seeing how to do it cleanly.
On another note: I certainly appreciate all the work you guys are doing,
but I seriously think you're making a lot more work for yourselves than
is necessary - or perhaps that should be rephrased as "a method that
worked moderately well in the past is simply being swamped by the load,
and you're losing ground because of *.answers' great success".
>From a reliability aspect, there's simply too much manual work implicit
in the published rules and procedures. For example, having the archival
software get into a tizzy because a Subject doesn't match some ad-hoc
regexp written by someone else on another machine tells us that something
isn't done in a reliable fashion.
Last I heard, you were using Kent's rkive software to do most of the work
with some additional stuff to try to produce links to file names constructed
from the subject line. Rkive doesn't really care about anything except the
Archive-name.
It seems to me that you could completely eliminate several of the changes
requiring moderator approval simply by making some slight modifications
to the "file-by-subject-line" code. Ie: all you need do is remember
the subject line from the last time a FAQ arrived, and when the new
FAQ arrives, you remove the file generated by the subject line of the
old FAQ too rather than hoping to overwrite it. Then you shouldn't need
prior approval of subject lines at all - at worst you'd need to write
a function to strip illegal characters out of the subject line, or perhaps
something to ensure that you're not overwriting someone else's faq (eg:
checking to see if the Archive-names match before deletion).
It seems to me that some of these changes would have a break-even period
in terms of your effort of less than two weeks, and by the end of a month
or two, your queues would be back to a few days.
I'm willing to give a hand in some of this, unfortunatly, the facts of
my network connectivity preclude me from offering to join the moderation
team. One thing I could do, perhaps, is to try to install a clone of
the RTFM archival software on my machine, and design/implement some
incremental fixes specifically designed to reduce manual intervention
that you could consider adopting. Perhaps I could even write a
by-mail change checker/approver filter that could give the FAQ author
approvals for classes of changes that can be automated.
-- Chris Lewis: _Una confibula non sat est_ Phone: Canada 613 832-0541 Ferret list: ferret-request@ferret.ocunix.on.ca Latest psroff: FTP://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/* Latest hp2pbm: FTP://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/*
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Landfield Group, 1997
All rights reserved