home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / c / cel142.zip / CEL142A.ZIP / BETATEST.NFO next >
Text File  |  1992-12-14  |  3KB  |  68 lines
  1. Celerity Beta Site
  2. ~~~~~~~~~~~~~~~~~~
  3.         Many people have expressed an interest in being a beta test site
  4. for Celerity BBS.  Most of them do not realize what it entails, however,
  5. so I have put this file together.
  6.  
  7.         Being a beta site means more than running the latest version
  8. before the public release is made.  It entails running potentially buggy
  9. software, working through frustrating conditions, and your board
  10. spending a bit of downtime.  Your responsibilities as a beta tester
  11. include calling the support BBS to pick up regular beta releases (often
  12. once every couple of days), and most importantly, writing bug reports.
  13.  
  14.         A bug report should list bugs in the following format:
  15.  
  16. 1:  Name / nature of the bug.
  17. 2:  Location and conditions of the bug's appearance.
  18. 3:  Whether or not you could repeat the bug.
  19. 4:  Version / beta date of the software you are using.
  20. 5:  If there is any special hardware (ie: a non-hst modem, for example)
  21.  
  22. Example:
  23.  
  24. 1:  I get a RUNTIME ERROR 200
  25. 2:  When I load up the sysop online tools' user editor
  26. 3:  It repeats with certain users, does not appear with others
  27. 4:  I'm using 1.42 beta #2, 11/24/92 version
  28. 5:  No unusual hardware
  29.  
  30.  
  31. Bug reports should be contained in a standard ASCII file with the
  32. extension of BUG.  Valid names are "CIT137.BUG" or "ALTEREGO.BUG".
  33. Suggestions for new features or improvements are welcome, but they
  34. should be in a seperate .SUG file, as I rarely go after both at the same
  35. time.
  36.  
  37. IF FILES DO NOT HAVE  .BUG or .SUG EXTENSIONS, THEY WILL NOT BE SEEN. IF
  38. THEY ARE ZIPPED, THEY WILL NOT BE SEEN.
  39.  
  40. I download all my bug reports into a directory, copy them all into a
  41. response file, and delete the bug reports.  I do this with dos
  42. wildcards, if the reports do not match the wildcards, they do not get
  43. looked at.
  44.  
  45. After going through and reading bug reports, I will sometimes issue .RES
  46. files, which will contain my responses to some of the bugs presented.
  47. These will range from "That's a bug I'm aware of", "Really? Never saw
  48. that..", "Yeah.. keep bugging me about it and I'll fix it eventually"
  49. and "Hmm.. that's a configuration problem - in your setup, change....".
  50. They are worthwhile reading though, and sometimes I'll ask for
  51. clarification on a problem.
  52.  
  53. The way that beta sites for a new version will be chosen is by the
  54. quality of the bug reports for the previous version.  For example, I
  55. will choose 4 beta sites from those sysops who upload bug reports on the
  56. 1.39 release version - tell me of any bugs you find in the 1.39 release.
  57. Bug reports are NOT judged on the number of minor nit-picky bugs you
  58. find (although do leave those for me if you want them fixed) or on the
  59. bugs you can copy from someone else's report.  What I am looking for is
  60. thouroughness, accuracy, and promptness.  Those reports I get earlier
  61. will stand a better chance.
  62.  
  63. I have decided to use this method because about 75% of the sysops wanted
  64. to be beta sites, but only about 25% of them wanted to do any work with
  65. it or put up with the trouble it can sometimes entail.
  66.  
  67.  
  68.