On Wed, 12 Jun 2013 20:50:12 +0200 RGB ES <rgb.m...@gmail.com> wrote:
> 2013/6/12 Donald Whytock <dwhyt...@apache.org> > > > On Wed, Jun 12, 2013 at 2:22 PM, Rory O'Farrell <ofarr...@iol.ie> wrote: > > > > > On Wed, 12 Jun 2013 13:35:23 -0400 > > > Rob Weir <robw...@apache.org> wrote: > > > > > > > Something to consider for AOO 4.1 is the value of a broad public beta > > > > program to solicit early feedback on builds. This could be a good > > > > complement to our formal QA efforts. > > > > > > > > A beta program could be set up like this: > > > > > > > > 1) After feature freeze, and after smoke tests pass on the 3 major > > > > platforms, we have a build that has the new code, and doesn't have any > > > > known horrible defects. > > > > > > > > 2) Immediately create a special Release Candidate for the beta, > > > > English only, or maybe a combination install with 5 major languages. > > > > > > > > 3) Vote on the release of the beta via the normal 72-hour PMC vote. > > > > Focus on the formal release checks around license, notice, etc. > > > > > > > > 4) Distribute via SourceForge and/or Apache mirrors. No need to > > > > preserve older betas. We'd only keep the most recent one. > > > > > > > > I just want to make sure that we're all aware this option is > > > > available. We can do something that gives wider public exposure than > > > > a dev snapshot build, but is less than a final version. The key thing > > > > is to meet the formal requirements of an Apache release, but set user > > > > expectations that it is a beta. > > > > > > > > Regards, > > > > > > A very major problem is that relatively inexperienced user _will_ > > download > > > and use a beta, disregarding any warnings about it being a beta. They > > will > > > increase the support workload, as faults may be due to their > > inexperience, > > > not to shortcomings in the beta, and certainly the stress level for > > support > > > staff as they are hassled to try to obtain recovery of "the most > > important > > > file this load of **** has ruined on me". > > > > > > A lot of projects list multiple versions of their software with the most > > "stable" at the top, and other versions provided below with multiple > > caveats attached, such as, "This is the most bleeding edge version we've > > got right now, download and try at your own risk...but please provide > > feedback if you do." > > > > As long as the first entry is described as the stable one, I'd like to > > think users would get that one. But I've heard I can be naive. > > > > > I don't think that a lot of users will overlook a big and flashy warning > (I've seen users afraid to download 3.4.x because it said "incubating"), > but I'm pretty sure that those few that actually download a beta without > worrying about what a beta is will be far more vocal than the others... > > Just a thought: is it possible to force those beta releases to open on > launch a one page document telling (better wording needed, of course...) > "I'm a development version! Use me at your own risk! Download the latest > stable release from here"? > > BTW, I really like the idea of a public beta program. We just need to be > very careful about how to promote it. > > Regards > Ricardo > > > > > Don > > I think Ricardo's idea is a good one; I'm sure he sees, from his forum experience, as I do, the problems from and the risks to the inexperienced user of a beta. Some form of double warning, as he suggests, would be good. I acknowledge that experienced users do make a valuable contribution in beta testing. I think what I'm really suggesting is that we need to protect inexperienced users from themselves. -- Rory O'Farrell <ofarr...@iol.ie> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
