What are we actually doing to put those words [from the letter from the chairman] into effect this year? What are we actually changing?

Stage one is we're committing more resources to fixing issues that affect the live environment, but also that are reported by players. And so in a typical setup, we have to take those resources from features. So that means that normally if we're on 50 different features, all these engineers are working on new content, to build new components or new features, new UIs for these new gameplay elements. And this can go on for a while because there's prototyping, there's iteration, there's merging, QA, and this can take a while to bring it in. And as Chris is pointing out, it creates ripple effects. And so we have to slow down on the features to get those resources to jump into what I call these Katamari issues. Like we're going to look at a couple later, but issues that require, oh, I need a physics expert. Oh, I need an audio expert. Oh, I need a graphics expert. Oh, I need a gameplay expert. I need a guy who wrote this system. I need a guy who wrote this system. An issue that just keeps growing until it's solved. In order to do that, we need to give a Joker card to those issues. And so that's what we're going to do this year, is to slow down on features. We still need to build features, but we're going to pick the ones we can do, while still investing in correcting the problems that we know have been in the game either forever or they're new and very active. And even if they're super complicated to solve and require a refactor, right? So we'll talk about refactors, I'm sure, in the next list. But it also means, what I put in my notes, because we kind of prepared a list so that I can just organize my thoughts, increasing bug fixing quotas for teams. So in general, teams have not necessarily a quota to fit, but they have a lot of time for bug fixing. We're going to try to bump that by a lot so that we can actually jump on more bug fixes that matter. That's the thing that's key, right? Even though we fixed 3,000 issues, there are maybe 15 or 20 or 30 issues that are really affecting players day in and day out that are bugs or defects that must be resolved. And so we've put that in a list called the Director's List. So every director has a chance to basically flag an issue in their domain and say, I'm going to need a Joker card for this issue and it needs to be solved. And so that list is also going to transform itself into a release criteria. Typically when we do a PTU, we're going through these waves. The process at which we go to the next wave is always a bit, it looks good, we look at metrics, we look at disconnects and stability in general, but we don't necessarily look at quality of the game specifically because we're in development. And so it's always been a bit different for us. But I think that we need to change this process for us to move away from being an alpha game. We need to start moving away from the words constant development. In order to do that, we need to professionalize our criteria for launch. And that means that director's list needs to go down. It needs to get the solves that it needs. And those become criteria to move forward. Now, we're going to have to make decisions because we cannot fix everything at the same time. Again, it's a question of resources. The goal is to make a significant dent in that list, even if it keeps going up there.

You said increase the number of engineers and programmers. You're not talking about going out and hiring 100 new people. You're talking about the people who were working on base building, the people who were working on crafting, the people who were working on resource networks. It's about taking those seniors, those people with the experience, the ones that Uno Mas said, the experts. It's about taking those experts and pulling them off the new feature development and putting them on the less sexy stuff like, hey, fix an elevator.