Re: Duration of beta period

> You've totally lost me here ... how do you speed up a beta when there are
> unknown number of bugs that have to be resolved before a release can
> happen? A beta's duration is as long as it takes to be stable ...
>
> Personally, I think this last beta period was one of our best ones yet ...
> considering the negligible number of bug reports following the release, we
> did exactly what had to be done in teh beta to make sure that the end
> result was as stable as possible for the testing pool we had ...

It was a good period, but we were in beta longer than we were in
development. That isn't good, and I think we could have shortened it if
we had pushed people to test beta sooner and harder, avoided some
sideroads in improving things that could have waited for 7.3, and pushed
a few people to complete bug fixes quicker than letting it all wait
until the end of beta. Of course, I may be wrong. :-)

> Don't start trying to set arbitrary dates on when a beta should start, or
> end ... you'll just screw with what is already a very effective
> development model ...

I sensed people were not happy with the beta duration. I think it was
sort of like being on a baseball team, and someone hits the ball to an
outfielder, and they drop it, and you feel, "Hey, my team stinks."
People like to be in groups that can successfully get things done, and
in a timely manner. No one wants to wait for the last person to get in
the bus so we can leave. If we don't tell people when the bus is
leaving, and just say, hey, get on the bus as soon as you can, it
doesn't seem to work as well as saying, "We are leaving in one hour. Be
on the bus, or explain why we should wait another hour." Of course,
just an analogy, but I think it has a point.

> If you are so bored that you need to organize something, come up with a
> list of what we hope to accomplish for v7.3 and use that for a guideline
> for when the beta will start ...

That is a tough one, and something that seems very hard to organize, but
I can try if you wish. The TODO list can easily be used for that.
Another marking stating "Will be done for 7.3" is all it needs. When
all the marks are turned to dashes (done) we are ready for beta.

> What major items do ppl have planned for v7.3? Once those items are
> completed, then we go into beta for v7.3 and beta lasts until we've gotten
> her to the point that she's as bug free as she can be without more
> extensive/broader testing ...

That is a good question and something we do need to ask. Thanks.

> If those major items are done on the 1st of April, I'll happily declare it
> the shortest development cycle we've had to date and go beta ... if it
> takes until the 1st of September, so be it ... but its not going to go
> beta until its ready, and its not going to be released until its ready ...
> and setting some arbitrary date is going to do one of two things: a)
> pressure developers into making mistakes that will make us look bad, or b)
> stiffle development while one developer figures "no way I'll get it done
> by then, so why bother" ...

Agreed, don't release until it is ready, but I think we could make it
ready faster with some dates. I am feeling people are doing beta
testing only near the end of beta because they realize how long it is
taking. That is bad. There is always pressure to lengthen the
schedule. I think we need some pressure to shorten it. That is all I
am saying.

> ... and that isn't to throw in the users that are going to say "but you
> said ... "

Agreed, we certainly want to stay away from that --- users holding us to
our dates is a recipe for disaster.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026