I thinks this needs some brainstorming because there are some use cases to consider in order to avoid collateral damage - and again complaints.
I'd use the rule: you're a beta tester? so NO COMPLAIN!!!
Only feedback!
I doubt that this is the right approach. Do you think you will encourage a large field test group to participate with that attitude?
Moreover no one is willing to test, if you harm or endanger their productive environment. How many would set up a secondary PC only for doing beta testing?
That is something you can expect from paid professional tester, but not the majority of a product with comparable small user group.
I think the easier and safer you can parallely test new versions, the more are willing to do so and contribute - and that is the aim of the game.
On the contrary, beta testers are...testers.
In order to be an effective beta tester, you need to put aside your own goals and actually test the product. This means that you should be keeping accurate records of what you are doing. When you come across a problem, you should be able to do some level of investigation yourself, so that you can create an actionable bug report for the development team. Depending on the needs of the development team, you may be able to do your own work, with your own workflow. But you should be prepared to set aside your own work to do various tasks as requested by the development team.
I am a professional software developer who's run a number of large scale beta tests. Testers who fall into the above category get lots of our attention. We try to discourage folks who are mainly interested in early access to the "latest and greatest". We inevitably get them, and they are useful for "taking the temperature" of the product to see how much noise they generate. But it is a lot of work to follow up on "complaints" without sufficient supporting documentation to investigate the issues. With a small enough development team, it might actually hinder product development.
I've also participated on a very limited number of beta tests for astronomy software. In one case, I put my own imaging goals on hold for almost a year so that I could focus on the software I was testing. It was work on my part, but it made the end product better, which was what I wanted to help with.
As for PixInsight, I think that it's an impressive accomplishment. I know what goes into making a product like this, and my hat is off to Juan and his team. There is a huge amount of hidden work that goes into making something like this work in a cross platform environment, especially when one of the platforms is Windows. While it's true that there have been some stability problems with Windows in the recent versions, it looks very much to me like Juan is making the right changes to resolve them (and to be fair, most of the the root problems aren't even in PixInsight itself, but in 3rd party libraries on which it depends).
