Article View: comp.sources.d
Article #700Re: comp.sources.reviewed and a blast from the past
From: Tom Lane
Date: Tue, 18 Aug 1992 00:46
Date: Tue, 18 Aug 1992 00:46
51 lines
3437 bytes
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!tglReferences:
<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