home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sources / d / 1192 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.sources.d
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!cs.utexas.edu!sun-barr!ames!pacbell.com!jmcarli
  3. From: jmcarli@srv.PacBell.COM (Jerry M. Carlin)
  4. Subject: Re: comp.sources.reviewed and a blast from the past
  5. Message-ID: <1992Aug18.153042.12235@PacBell.COM>
  6. Sender: news@PacBell.COM (Pacific Bell Netnews)
  7. Organization: Pacific*Bell
  8. References: <1992Aug14.150535.15169@rick.dgbt.doc.ca> <1992Aug17.023423.14527@virtech.uucp> <Bt5M67.273.2@cs.cmu.edu>
  9. Date: Tue, 18 Aug 1992 15:30:42 GMT
  10. Lines: 44
  11.  
  12. In article <Bt5M67.273.2@cs.cmu.edu> tgl+@cs.cmu.edu (Tom Lane) writes:
  13. >cpcahil@virtech.uucp (Conor P. Cahill) writes:
  14. >
  15. >> I think the 
  16. >> community would be much better served by a much faster and much less 
  17. >> nit-picky mechanism that precluded a reviewer from being able to say
  18. >> things like, "I don't like the way he did that".    
  19. >
  20. >Well, I think that even very nit-picky comments may be valuable...
  21. >
  22. >On the other hand, if the process allows a reviewer to *prevent a package
  23. >from being posted* on the basis of minor quibbles, that is a big problem...
  24.  
  25. I can speak from personal experience since I've reviewed a few packages.
  26. What I've tried to do is separate the nits from the major items and to
  27. follow the voting guidelines that are the same as what we use for walkthrus
  28. BTW ->
  29.  
  30.     Would you suggest that this submission:
  31.  
  32.        - be accepted for posting as is
  33.        - be accepted after minor revisions (that you have detailed)
  34.        - be returned to the author with a recommendation to make
  35.            major changes and re-submit
  36.        - be rejected
  37.  
  38. In one case at least the author disagreed with some of my "minor revisions"
  39. or agreed to make them in a future release but I said ok the second time
  40. anyway.
  41.  
  42. If one reviewer was being overly finicky, I think the process would still
  43. work fine since other reviewers would balance the one holdout.
  44.  
  45. Actually I think the biggest problem is getting enough reviewers with
  46. time and interest to check some software out. I've seen 2nd and 3rd
  47. call for reviewers for some packages and have felt guilty that I did
  48. not have time to lend a hand.
  49.  
  50. So if you've got time and interest sign up and help the process! If you
  51. think people are too nit-picky, sign up and be more accepting of minor
  52. stylistic differences! Reviewing is a democracy as far as I can see!
  53. -- 
  54. Jerry M. Carlin    (510) 823-2441 jmcarli@srv.pacbell.com
  55. Alchemical Engineer and Virtual Realist
  56.