home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
BBS
/
CEL138A.ZIP
/
BETATEST.NFO
next >
Wrap
Text File
|
1991-11-17
|
3KB
|
62 lines
Celerity Beta Site
~~~~~~~~~~~~~~~~~~
Many people have expressed an interest in being a beta test
site for Celerity BBS. Most of them do not realize what it entails,
however, so I have put this file together.
Being a beta site means more than running the latest version
before the public release is made. It entails running potentially
buggy software, working through frustrating conditions, and your board
spending a bit of downtime. Your responsibilities as a beta tester
include calling the support BBS to pick up regular beta releases
(often once every couple of days), and most importantly, writing bug
reports.
A bug report should list bugs in the following format:
1: Name / nature of the bug.
2: Location and conditions of the bug's appearance.
3: Whether or not you could repeat the bug.
4: Version / beta date of the software you are using.
5: If there is any special hardware (ie: a non-hst modem, for example)
Example:
1: I get a RUNTIME ERROR 200
2: When I load up the sysop online tools' user editor
3: It repeats with certain users, does not appear with others
4: I'm using 1.37 beta 8/16/91 version
5: No unusual hardware
Bug reports should be contained in a standard ASCII file with the
extension of BUG. Valid names are "CIT137.BUG" or "ALTEREGO.BUG".
Suggestions for new features or improvements are welcome, but they
should be in a seperate .SUG file, as I rarely go after both at the
same time. As of version 1.39, I will not look at files not
conforming to these filenames.
After going through and reading bug reports, I will sometimes issue
.RES files, which will contain my responses to some of the bugs
presented. These will range from "That's a bug I'm aware of", "Really?
Never saw that..", "Yeah.. keep bugging me about it and I'll fix it
eventually" and "Hmm.. that's a configuration problem - in your setup,
change....". They are worthwhile reading though, and sometimes I'll
ask for clarification on a problem.
The way that beta sites for a new version will be chosen is by the
quality of the bug reports for the previous version. For example, I
will choose 4 beta sites from those sysops who upload bug reports on
the 1.38 release version - tell me of any bugs you find in the 1.38
release. Bug reports are NOT judged on the number of minor nit-picky
bugs you find (although do leave those for me if you want them fixed)
or on the bugs you can copy from someone else's report. What I am
looking for is thouroughness, accuracy, and promptness. Those reports
I get earlier will stand a better chance.
I have decided to use this method because about 75% of the sysops
wanted to be beta sites, but only about 25% of them wanted to do any
work with it or put up with the trouble it can sometimes entail.