🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sources.d
Article #700

Re: comp.sources.reviewed and a blast from the past

#700
From: Tom Lane
Date: Tue, 18 Aug 1992 00:46
51 lines
3437 bytes
cpcahil@virtech.uucp (Conor P. Cahill) writes:
> Also note that on 3/31 (the posting date) the code was already
> out of date by approx 2 months.  
> 
> >submitters are serious about their software, we are usually able to
> >complete a couple of rounds of reviews and get things posted within a
> >few months.
> 
> I think that is way too much time and too many reviews.

Speed is certainly an issue.  When you are dealing with software that may be
radically improved in the course of a few months, it makes no sense at all
to waste Usenet bandwidth on posting anything but the latest version.
Perhaps c.s.r needs to fine-tune their reviewing process so that an updated
version of a previously-reviewed program can be fed through very quickly.
(Maybe just verify functionality rather than do a full review.)  That way
you could make an initial submission, work on improving the package with
other beta-testers, revise the package per the reviews when you get them,
and resubmit with an expectation of seeing it posted almost immediately.
If c.s.r's model is that you do nothing while waiting for their review,
then they definitely have a problem.

> I think the 
> community would be much better served by a much faster and much less 
> nit-picky mechanism that precluded a reviewer from being able to say
> things like, "I don't like the way he did that".    

Well, I think that even very nit-picky comments may be valuable; I would
certainly want to hear every suggestion that the reviewers might have
(assuming they are knowledgeable people :-).  So I don't want the reviewers
to feel that they can't say "I don't like the way he did that".

On the other hand, if the process allows a reviewer to *prevent a package
from being posted* on the basis of minor quibbles, that is a big problem.
There needs to be an escape that lets an author say "maybe that is a good
idea, but I'm not going to do it".  c.s.r needs to have a policy that
determines how important a given complaint is, and whether it warrants
rejecting the submission if the author won't fix it.

If the hurdle is too high, I can well imagine authors submitting to c.s.r,
reading the reviews, taking the suggestions they like, and proceeding to
post to c.s.m or c.s.u rather than argue about the suggestions they don't
like.  Perhaps some of those missing resubmissions went to other newsgroups??

Of course, the whole point of c.s.r is to post only software that meets a
standard of quality defined by the reviewers.  I'm just wondering if the
standard is currently set a little too high, or if there is maybe not enough
flexibility in the process to accommodate reviewers' opinions versus
authors' opinions.

				regards, tom lane
Technical Details
Message-ID: <Bt5M67.273.2@cs.cmu.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!tgl
References: <22604.Aug103.47.2091@kramden.acf.nyu.edu> <1992Aug11.225255.22760@athena.mit.edu> <1992Aug12.152145.26416@osf.org> <1992Aug14.150535.15169@rick.dgbt.doc.ca> <1992Aug17.023423.14527@virtech.uucp>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!tgl
From: tgl+@cs.cmu.edu (Tom Lane)
Newsgroups: comp.sources.d
Subject: Re: comp.sources.reviewed and a blast from the past
Message-ID: <Bt5M67.273.2@cs.cmu.edu>
Date: 18 Aug 92 00:46:55 GMT
Article-I.D.: cs.Bt5M67.273.2
References: <22604.Aug103.47.2091@kramden.acf.nyu.edu> <1992Aug11.225255.22760@athena.mit.edu> <1992Aug12.152145.26416@osf.org> <1992Aug14.150535.15169@rick.dgbt.doc.ca> <1992Aug17.023423.14527@virtech.uucp>
Sender: news@cs.cmu.edu (Usenet News System)
Organization: School of Computer Science, Carnegie Mellon
Lines: 51
Nntp-Posting-Host: g.gp.cs.cmu.edu