🚀 go-pugleaf

In article <9979:Apr1122:30:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

   If this group is only going to accept software that works under BSD,
   System V, MS-DOS, the Mac OS, VMS, and VM/CMS (just to name a few), it
   won't get many submissions.

I don't follow that.  Don't most Internet users use those systems most
of the time, and most submissions to existing groups run on those systems?

   > Please use an informative "Subject" line when mailing postings.
   > Something like "nlist - New file list utility, Part01/04"

   Uh-oh. I can see the first few packages coming through now...

Yes, please rename submissions that have names that conflict with
existing programs that do something different!

   > Each submission should include the following types of files.  

   ``Types of files''? You mean not necessarily under those names?

Some authors prefer ReadMe, Install, or readme.doc, install.doc . . .
doesn't make much difference, does it?  (Well, uniformity is nice if
you want to find all the documentation at a glance.)  This point
should be clarified, though, whichever way.

   > but many users prefer that they be able to make
   >     and test software in the current directory before they install it.

   Is there anyone who doesn't prefer this? I really like packages that
   have a separate installation script; make does not work well for files
   in different directories, and I hate having privileged operations hidden
   inside a Makefile.

make -n doesn't work well enough?  It seems to be sufficient for me.
I agree that it's nice to be able to test something without having to
install it.  Complex packages with lots of support files should
probably support an environment variable or similar mechanism
specifying the root(s) of the directories they use.  Otherwise you
have to build it twice -- one time configured for a test location,
then again configured for the final installation location.

   > The preferred form for patches is "diff"
   > format, using the "-c" option to produce context diff files.

   The preferred form should be unidiff.

Good idea.  It would save a lot of bandwidth over time.  The
unidiff-aware patch program is easy to get from lots of ftp and uucp
archive sites.  Or it could even be posted to the newsgroup.  Maybe
GNU diff too.

   > - if submission is accepted:
   > 	- moderator discusses evaluations with author
   > 	- moderator posts sources and evaluations

   This is supposed to be modelled on traditional journal reviews, but
   reviewers don't get anonymity, and reviews are published. What a joke.

I don't recall whether the group's charter mentions this issue.
I don't know how closely the group ought to follow the traditional
journal review model; what is most appropriate for this medium?

   > We are discouraging making repairs to submissions during the review
   > process.

   Ahahahahaha. That's funny.

I agree; I think having the reviewers give the authors feedback, and
getting fixes from the authors for problems they find, would probably
speed up and improve the reviewing process significantly.

   > Once the reviews are completed, you will receive a summary from the
   > moderator, and, if necessary, will have a chance to make repairs to
   > your package.

   So will the package be re-reviewed after that?

That could entail a long cycle of submit-review-fix-submit-review-fix
etc. if authors aren't allowed to interact with reviewers.  Consider
the reviewers "post-beta" testers, and the submissions will probably
make it through the pipeline more quickly, without loss of quality.
Maybe with a gain in quality.

Of course, that would eliminate the reviewers' anonymity, unless you
interpose the group's moderators as middlemen in all communication
between authors and reviewers, stripping "From: " lines before passing
on the reviewers' comments.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>