Hi! Can you please explain the process of bug-tracking and solving in detail? What's the average time frame from reporting to solving bugs. How many people are involved in the bug solving process, etc? Can you explain the systematics of QA to avoid bugs in the first place?asked by Fuzzer

You kind of asked the right two people about that! How it works is, we have our QA testers, whether they're testing in game or we get bugs reported from you in the community, the bugs are then recorded within our own bug tracking software. From there the producers take a look at which developers have the bandwidth and what the nature of the bug is. So if it's going to be, for example a HUD or UI bug then chances are it would go to Zane. So we have producers look at everybody's task loads and assign those bugs out to each individual person, and we try to get rough estimates of how long each one would take to resolve from those developers. And that kind of helps us build our work load for particular week, or even month.

Yeah, no, it's gonna be kind of a bad answer to this question 'cause it's contextual, at least in regards to the part of "how long does it take to fix something?", right? So, a very important part of the bug process is, especially when we're in the finalling process right now, is triaging, right? So we get in issues reported by QA, and maybe something's really important to one guy, but it's not important for the product overall - so he marks it as "critical", we lower it to "moderate" or "trivial" in JIRA. (JIRA is the bug tracking software that we use). And essentially something, depending on the priority and how long it's going to take to fix, really informs the speed at which we're going to fix it. So for example in AC 1.0 we're focusing very heavily on these new ships that we're introducing that you'll see very soon (or have already seen depending on the air date of this episode), and what's cool about is a lot of the kind of more legacy ship issues, or things that we know we're going to go back and rework later, we're not going to end up spending time on them. So it's about prioritization and managing people's work loads against the milestones and releases that they have coming up. So to answer the length question, it might take five minutes to fix a bug bug it might not get fixed for a week, depending on somebody else's priorities, right?

Especially if we have something that's blocking us releasing the build, so you know, if you've got into a ship and the client crashes, even if that was a five minute fix, obviously that's going to be a higher priority than something like a gun's appearing slightly off. So it's just constant managing of priorities - what can we push back to the next build, or next version, or next update, given a limited time frame? Like right now we're so close to the 1.0 release, that we have to look at what bugs are not going to be important enough to push back.

Yeah, and if you want to impress your friends with, like, certain vernacular, that may or may not be commonly known... "WNF" - "will not fix", means if you get a bug and you look at it and you go, "meh, not high enough priority to fix for this release - WNF. Kick it off to the next version." If you get something that's tough to reproduce and you can see somebody spending sixteen hours on it because it's like, "oh, we had eight players, and 20% of the time when I think I was kinda doing this it maybe crashed" ... "CNR, low priority," so "can not reproduce, low priority. Give me better repro steps and we'll look into it, otherwise we're not going to waste the time on it for now."