Making the *.answer moderation process non-Unix dependent is a
non-core issue, just as earlier in this thread, somebody jumped on the
difference between text vs. GUI Web browsers when what was really at
issue was the fact that character-at-a-time data transmission is much
more sensitive to high latencies than block-mode data transmission.
A significant amount of effort was put into creating the current
infrastructure for the *.answers moderation process nearly a decade
ago. At that time, given what computing platform was readily
available to the creator(s) -- yes, the infrastructure was Unix-based
and expected moderators to have interactive shell access to the shared
filesystem where much tracking data is kept. Think of the *.answer
moderation process as a custom-built CRM (customer relationship
management) or bug tracking system, and you'll have the right idea.
The real core issue isn't that it's Unix-based now and wants to be
Web-based (for easier training of and easier access by new
moderators), but rather that developing *ANY* new infrastructure would
be a significant amount of work.
The latency issue shouldn't be as big a deterrent to potential new
*.answers moderators as it's been painted, though. The workflow
roughly looks like this:
(1) Look at the queue of pending requests, and grab some number of
requests out of the queue.
(2) For each request (grouping related requests together), send
correspondence back to the author of the posting and update the
correspondence records.
(3) Periodically checkpoint the correspondence records.
(4) At end of moderation session, either requeue requests which have
not yet been handled, or make sure that those requests are
handled first in the next moderation session, so that they don't
end up getting orphaned for any lengthy period of time. Ideally,
requests are *roughly* handled in FIFO order.
Step (1) involves a certain amount of interactive usage, since the
*.answers moderator will probably sometimes want to cherry-pick
certain categories of requests to handle, and/or make sure that
multiple requests which conceptually should be grouped together are
handled together, per my parenthetical remark in Step (2). E.g.,
somebody may submit a 6-part FAQ, then send a message noting that is
what they've done and add some additional information about the
submission. Ideally, all 7 queue entries should be grabbed by the
same moderator and processed during the same session. But they may
not be strictly consecutive in the queue, since other requests can and
likely would have arrived in the meantime. However, a view of the
queue can be easily generated and then viewed locally (via scrollback,
for example).
Step (2) is by far what a *.answers moderator spends the most time
doing during a moderation session. Reading and processing the
request, composing correspondence, updating the correspondence records
--- all these are things which the *.answers moderator can and
probably should do locally, during which time high latency to MIT
won't make any difference.
Step (3) would then involve uploading the local copy of the
correspondence records. Uploading being a block-mode operation, while
high latency wouldn't be entirely negligible, it wouldn't be a big
deal, either.
Step (4) is essentially a batch operation for which high latency is
also pretty much moot.
Right now from where I sit, my ping time to MIT is on the order of
250ms, but the latency certainly isn't what prevents me from becoming
an active moderator again. Rather, it's a lack of time. (And yes,
being honest with myself and with y'all, that really means a lack of
willingness and sufficient interest to *MAKE* the ongoing commitment
of time for this in my life right now.)
- Ping Huang <pshuang@alum.mit.edu>
*.answer moderator emeritus
*************************************************************
To unsubscribe send a message to majordomo@faqs.org as
unsubscribe faq-maintainers fill-in-your-email-address-here
*************************************************************
[
FAQ Archive |
Search FAQ Mail Archive |
Authors |
Usenet References
]
[
1993 |
1994 |
1995 |
1996 |
1997 |
1998 |
1999 |
2000
]
© Copyright The Internet FAQ Consortium, 1997-2000
All rights reserved