home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sources / d / 1188 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!tgl
  2. From: tgl+@cs.cmu.edu (Tom Lane)
  3. Newsgroups: comp.sources.d
  4. Subject: Re: comp.sources.reviewed and a blast from the past
  5. Message-ID: <Bt5M67.273.2@cs.cmu.edu>
  6. Date: 18 Aug 92 00:46:55 GMT
  7. Article-I.D.: cs.Bt5M67.273.2
  8. 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>
  9. Sender: news@cs.cmu.edu (Usenet News System)
  10. Organization: School of Computer Science, Carnegie Mellon
  11. Lines: 51
  12. Nntp-Posting-Host: g.gp.cs.cmu.edu
  13.  
  14. cpcahil@virtech.uucp (Conor P. Cahill) writes:
  15. > Also note that on 3/31 (the posting date) the code was already
  16. > out of date by approx 2 months.  
  17. > 
  18. > >submitters are serious about their software, we are usually able to
  19. > >complete a couple of rounds of reviews and get things posted within a
  20. > >few months.
  21. > 
  22. > I think that is way too much time and too many reviews.
  23.  
  24. Speed is certainly an issue.  When you are dealing with software that may be
  25. radically improved in the course of a few months, it makes no sense at all
  26. to waste Usenet bandwidth on posting anything but the latest version.
  27. Perhaps c.s.r needs to fine-tune their reviewing process so that an updated
  28. version of a previously-reviewed program can be fed through very quickly.
  29. (Maybe just verify functionality rather than do a full review.)  That way
  30. you could make an initial submission, work on improving the package with
  31. other beta-testers, revise the package per the reviews when you get them,
  32. and resubmit with an expectation of seeing it posted almost immediately.
  33. If c.s.r's model is that you do nothing while waiting for their review,
  34. then they definitely have a problem.
  35.  
  36. > I think the 
  37. > community would be much better served by a much faster and much less 
  38. > nit-picky mechanism that precluded a reviewer from being able to say
  39. > things like, "I don't like the way he did that".    
  40.  
  41. Well, I think that even very nit-picky comments may be valuable; I would
  42. certainly want to hear every suggestion that the reviewers might have
  43. (assuming they are knowledgeable people :-).  So I don't want the reviewers
  44. to feel that they can't say "I don't like the way he did that".
  45.  
  46. On the other hand, if the process allows a reviewer to *prevent a package
  47. from being posted* on the basis of minor quibbles, that is a big problem.
  48. There needs to be an escape that lets an author say "maybe that is a good
  49. idea, but I'm not going to do it".  c.s.r needs to have a policy that
  50. determines how important a given complaint is, and whether it warrants
  51. rejecting the submission if the author won't fix it.
  52.  
  53. If the hurdle is too high, I can well imagine authors submitting to c.s.r,
  54. reading the reviews, taking the suggestions they like, and proceeding to
  55. post to c.s.m or c.s.u rather than argue about the suggestions they don't
  56. like.  Perhaps some of those missing resubmissions went to other newsgroups??
  57.  
  58. Of course, the whole point of c.s.r is to post only software that meets a
  59. standard of quality defined by the reviewers.  I'm just wondering if the
  60. standard is currently set a little too high, or if there is maybe not enough
  61. flexibility in the process to accommodate reviewers' opinions versus
  62. authors' opinions.
  63.  
  64.                 regards, tom lane
  65.