Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!bbn!bbn.com!denbeste
From: denbeste@bbn.com (Steven Den Beste)
Newsgroups: comp.sys.amiga
Subject: Filtering the source/binaries without bottleneck
Message-ID: <34235@bbn.COM>
Date: 6 Jan 89 18:45:30 GMT
Sender: news@bbn.COM
Reply-To: denbeste@BBN.COM (Steven Den Beste)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 113


Our two recent experiences with moderators have each had good sides and bad
sides.

Bob Page is doing a great job in expediting postings to the group, but recently
he posted some things in excess of 2 megabytes to the binaries groups
which were useless to the vast majority of readers of the group. People have
begun clamoring for a pre-filter.

The only way that Bob, working ON HIS OWN TIME (let's not forget this),
has been able to expedite things through has been for him to do
minimal checking.

Before, Pat and Justin (and another guy whose name I've forgotten) used to
really test everything, but since this takes a lot of time and they didn't have
much to spare, there were delays of weeks, and the complaints were "Come on,
guys, expedite!". (If the crowd had had its way, Justin and Pat would have
worked full time on moderation.)

I'd like to express my opinion that all of them have done a good job. If there
has been a problem, I think it is with the process, not the
people. The purpose of this report is to propose a different process,
which I think is better than either of the two we've seen before.


Through-out this, I'll use the term "Page" to refer to the primary moderator,
though Bob Page's direct involvement in such a process is entirely up to him...

Page keeps a list of volunteer testers, and for each he has a list of hardware
and major software, and interests and expertise.

When he receives a submission, that submission must have at the beginning the
following information: What is required in the environment for this to run, and
for source what language tools are needed to manufacture it. (So things like
amount of RAM, amount of disk space, NTSC/PAL and suchlike are here.)

Anyone sending in a submission without this information gets a form letter in
the email, and the submission is stored until that information is provided.
If the submitter can't be reached, or after 30 days without an answer,
the submission goes in the byte bucket.

With this information in hand, Page checks his list of testers to see who can
test it, who hasn't been as busy as the others. (By which I mean that Page
tries to spread the load fairly evenly within the limits of requirements.)

He ships off a copy of the submission to that tester. The tester must either
test it within a week, or send back a letter within that week saying how long
it will take to test it and give a reason for the delay. Page might reassign it
if he chooses.

If Page can't readily find an appropriate tester, he sends a description of the
submission and required environment out to an exclusive mailing list of all the
testers (and no-one else) asking for a volunteer. If none can be found, Page
informs the original submitter, and the project is dropped. (Alternatively,
it might be posted with a caveat.)

[Another possibility is that Page posts the description and requirements to the
net and asks for a volunteer to join the tester corps.]

[Oh, yeah: And whenever Page sees someone out there bitch and moan about
comp/[sources|binaries]/amiga speed, he sends a test package to that person -
put up or shut up. :-)]

As the tester works, he/she keeps notes, and when done returns the following
testing report:

     Name of program:
     Date of submission:
     Author name and net address:
     Tester name and net address
     Function of program:

     Tools and versions needed for compilation:
     Hints and tricks in compilation:

     Environment requirements to run it:
     Observed bugs:
     Unusual behavior, perhaps attributable to it:
     Hints and tricks for use:

     Do you intend to keep using it?
        If so, for what?
        If not, why not?


This report (plus maybe the test package itself if the tester had to change
anything to get it to work) is sent back to Page.

If there is a decision to let the submission through.
Page posts the test report to comp.sys.amiga, and packages the test report into
the ".zuu" which is posted to the source and/or binary group.

If Page and the tester decide to block the submission, the test report is
returned to the submitter, to allow correction of problems.


To make this work, the tester group needs to be 5-20 knowledgeable users with
large machines.
(Though it might not be bad to have a couple of people with minimal systems on
the list, such as a A500/512K/1 drive and nothing else...) I volunteer to be on
this list.

I believe this gives us the best of both worlds. Justin and Pat gave us
quality moderation, but at a big loss in speed because the testing process
was a bottleneck. But if it is
divided among 10 or 20 people, it isn't too bad. Page's job gets only a little
bigger under this process, so he should be able to work just as fast as he has.

I would like to hear discussion of this.


Steven C. Den Beste,   BBN Communications Corp., Cambridge MA
denbeste@bbn.com(ARPA/CSNET/UUCP)    harvard!bbn.com!denbeste(UUCP)