At the same time I feel that a desire for early access is the only reason to do unpaid testing. Unless one has an interest in the subject, why spend time dealing with bugs in an incomplete product? I've always viewed it as a trade; I want to play with something, the developers want to know what works and what doesn't. I don't do a lot of testing, because frankly it turns fun time into work more often than not, but I guess I'm feeling...protective of the EU? Like I've been so disappointed by everything Star Wars of late that I just want this to be good.
There's different types and phases, and depending on the phase, it's really not about playing the mod, in terms of how a person would typically think of that (like, just playing around and on the off chance something weird happens, reporting it) at all. That's
why we limit in in the way we have, as I explained in the update, and why it gets progressively more open, as we solve the more game breaking issues (which tend to require smaller pools of people to find, and, for obvious reasons, we want to limit to as few people experiencing as possible, while also not pointlessly flooding our inboxes).
When we're testing the mod internally, with the internal testing team, it's almost completely "work" because it's mostly repeatedly just trying to break specific new features. When it's in the Admiral's Lounge, it'll be semi-work and more on the "just play and tell us when you come across something weird" side, because there'll still be those major problems, but fewer. Then, when it hits the actual, full open beta phase, as we've said it will after the Admiral's Lounge, then yeah, it'd valid for people who "just want to play early" to want to jump in, because it's mostly playing and very little work. The thing we want to discourage is people who think any and all testing, from internal to the semi-open phase, fits into that category.
At the same time I feel that a desire for early access is the only reason to do unpaid testing [...] I want to play with something, the developers want to know what works and what doesn't.
When we're picking internal testers, we have the same overall criteria as with any other position in the mod- is their primary motivation that they wanna be involved with making the mod better, and do they have the skills to do that (being the ability to provide cogent feedback on things, and can they help narrow down stuff to find what's specifically breaking). When we pick internal testers, we're testing almost throughout the entire dev cycle, and it's not just us handing off the mod and people go to either test or not test. I spend a lot of time getting them set up, doing writeups on what to expect, what's broken or not broken, what our rough timelines or plans are, and interacting with them more 1-on-1 to fix things, get feedback, etc. It's only feasible to have so many people doing that, and we only need so many people doing that.