The embedded green light is what you just got done talking about, letting QA manage their priorities and green-light things?
TL;DRHero-squad developers must explain the problem and get a proposed fix validated before coding, while embedded QA testers can now red-light any change before submission, aiming to cut regressions.
No, that one's a bit of a separate one, actually. So the hero squads is really about getting our QA team to drive the priority on a specific subject and drive down, right? One of the changes in methodology for the devs on those teams is a bit of a change in approach. In code review in these hero squads, we no longer just accept the fix based on code change. We ask the developer to explain what the problem is: can you reason why this is happening? Second, propose a change. And then the leads can validate this change before we start even writing any code for it. And then we verify the change with QA. And then that's when we actually allow the change to come into the stream at all. So we do a lot more work before the work is actually started, a lot more work validation before it actually gets submitted. On those teams, developers working on those hero push squads have a much more methodology to apply to solve that. Because basically, in the past, the regression rate was too high. And so the big advantage of that setup is that those teams are faster to react, because they're dedicated on one subject. And so if there is a regression, because they still happen, they're faster to pick it up. But then the fixes are slower to put in. But that still has been very effective. So transit is one of our hero push squads, which to me has been kind of successful since the beginning of the year. I think the transit system, we're going to talk a bit more about it later, it's in a much better shape. The embedded green light is what you just talked about, which is, that was a major organizational change. And so in the past, the way that game devs at CIG on Star Citizen would work is that they would submit and test later. Now that sounds crazy, but it is what it is. And it was what it was. And so at the beginning of the year, we completely changed this. And so we added this embedded green light process. So what is an embedded? So embedded are QA testers that are embedded in a dev team. Everybody has a view of there's a floor of QA people and then they will receive a build and they test the build and stuff like that. But there's another class of testers that are embedded in teams and they become specialists in what that team is doing. So if you have an embedded tester in the FPS weapon team, those people know all about FPS weapons, how to test them, what change affects what, and so they can judge what they have to test. So the embedded green light is we gave that team the power to red light any change before it's submitted. And so that's a big culture shift because it used to be hot and fast. Get it in. We'll test and fix later if there's issues. And we trust devs. We don't trust devs. We need to verify. We need to check it. And the whole point of this was to hit on regression or side effects because our rate of regression and side effects was extremely high.
No, I mean, we've had embedded QA for years. This was about empowering them, in order to be a bulwark against letting the stuff through.