home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sources / d / 1247 < prev    next >
Encoding:
Text File  |  1992-09-07  |  2.0 KB  |  41 lines
  1. Newsgroups: comp.sources.d
  2. Path: sparky!uunet!decwrl!csus.edu!netcom.com!mats
  3. From: mats@netcom.com (Mats Wichmann)
  4. Subject: Re: comp.sources.reviewed and a blast from the past
  5. Message-ID: <aannz1.mats@netcom.com>
  6. Date: Sat, 05 Sep 92 06:06:25 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <1992Aug14.150535.15169@rick.dgbt.doc.ca> <1992Aug17.023423.14527@virtech.uucp> <Bt5M67.273.2@cs.cmu.edu> <1992Aug18.153042.12235@PacBell.COM> <1992Aug19.112600.1288@virtech.uucp>
  9. Lines: 30
  10.  
  11. cpcahil@virtech.uucp (Conor P. Cahill) writes:
  12.  
  13. >Before I run off, I want you to know that I don't think c.s.r is a bad
  14. >idea, I just feel that it has placed too much power into the reviewer's 
  15. >hands.   Since the software is the product of the author, only she
  16. >should have the right to require changes to it.  A reviewer's job should
  17. >be to look at the software and comment on what they think of it.  
  18.  
  19. >If the author still wants to post software with bad reviews, let her have
  20. >that choice.  The group still serves the purpose of having reviewd the
  21. >code and having given the result of the reviews to the community.
  22.  
  23. That's one (quite valid) way to look at it - like movie reviews.  Bad
  24. reviews might not keep the studio from releasing - or they might, but
  25. it's their choice.   Another way is to draw a comparison with the
  26. reviewing of papers for scientific journals - or even of books for
  27. publication.  I've never reviewed software on this basis, but I've
  28. reviewed books and refereed articles, and I've felt no qualms about
  29. suggesting that the work not be published in its' condition at the time
  30. of reviewing.  I've even received letters of thanks for constructive
  31. reviews which caused the publisher to have the author go back and make
  32. changes prior to publication.
  33.  
  34. Which model should c.s.r follow?  (I won't take a position).
  35. -- 
  36. Mats Wichmann
  37. Unisoft Corporation
  38. mats@unisoft.com (or mats@netcom.com)
  39.  
  40. Silly Disclaimer:  speaking only for myself, except when I'm not.
  41.