Again - how exactly will a better QA process bring immediate benefit to the project, if we fail to draw the big potential benefit out of the process we alreay have? By big potential benefit I mean that Haiku would already be so much more polished if a big chunk of all existing tickets were fixed rightnow. The main problems are lack of time and/or motivation. How will abetter QA process help with that? More likely (IMHO), it has the potentialto cause even more frustration when tickets just linger if the one who prepared it put even more effort into it.
Better QA is not necessarily about finding even more bugs. It can be checking that old bugs are still reproductible in recent builds, investigating way to trigger the bug, and perhaps even searching for the source of the problem, linking tickets that seem related, and so on. About anything we already more or less do on trac besides writiing code, actually. I think the QA team could get permissions to close/assign/... tickets as developpers do, but no access to the svn, for example. On the other side, the QA is done on code cleanliness on the mailing list after someone commits something. It's about checking if the code runs and does not break the build, but also checking it fits the coding guidelines.
Most of these things the developpers are already doing in more or less formalized and automated ways. But a formal team could help even if they don't know much about the code.
-- Adrien Destugues / PulkoMandy http://pulkomandy.ath.cx
