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