How Bug Reports are Managed - i.e. What Happens Next¶

So you've submitted the perfect bug report, but your interested in what happens to it after that?

In a nutshell reported bugs go through a number of stages, and here's some information on those steps (FYI These steps are very similar to the processes the test teams use in QA and Experimental testing)

People Involved¶

There is a team of testers and other interested people who look through these bugs and aim to assist those who have issues as well as helping to identify when bugs need to be brought to the attention of developers. Please keep in mind that the more comprehensive and complete any submitted reports are, the faster these can be processed, investigated and escalated. If it does look like nothing has happened to your report, please review it and see if it can be improved.

Triage/Confirmation¶

The first step when a "new" issue is reported is that the bug report is reviewed to check a few things:

1. Firstly, is it an issue that has been previously reported/already a known bug - even though you may search the bug tracker before reporting a bug sometimes we do end up with duplicates. In this case the older bug report will be updated and linked to the new one and the newest one closed as a duplicate.
2. Then we look to replicate the issue - is the information and steps in the report sufficient for someone else to be able to replicate the results reported. If people can't replicate the issue using the steps then there may be some back and forth to get some good quality steps
3. Adding any extra detail - In this last part of triage we might be adding some details around any missing categories, version specifics, etc

Investigation¶

Once we have a reproducible bug report, the next step is usually to see if we can find the cause of the bug. This involves having good knowledge of the way KSP works and we usually get to varying levels of detail in this phase depending on where the bug lies.

The aim here is to pinpoint as closely as we can what section of the game is causing the bug, so the developers can get to the meat of issues as quickly as we can help them to.

You may get more questions at this phase if your bug is being investigated. We may need to ask for more detail or ask you to help with narrowing it down.

If you would like to see some more of the methods we use when trying to track down bugs we will add some details on methods here shortly

Escalation¶

While we cant give you exact details on every issue and how they are hand;led specifically, below are some guidelines on how the escalation usually works:

• Confirmed issues are brought to the development team to look into fixing for an upcoming update.
• Significant issues are escalated to the dev team to see if they qualify for a hotfix or patch.
• Minor issues are usually noted and fixed when and where possible, during the course of usual development.

Resolution¶

With the development cycle that is used for KSP code changes are committed and tested through releases. This means that bug fixes will be included in each new release. After versions are released we will typically review the open/outstanding bugs and close off the ones that have been resolved.

In the process the QA team will identify the tickets in the Public Bug Tracker, mark them as confirmed when the issue can be reproduced, assign those tickets to themselves for followup and updating, bring them to the attention of developers in an internal Bug Tracker. Once the issues have a stable fix that is confirmed and in line to be part of the next release, the QA team will mark the tickets in the Public Tracker as Being Worked, and, once the release is out and the fix available, the tickets will be marked as Ready to Test and we will await input from players about the fixes.

This is a background task though, so most people notice their bug being fixed in the release, before the issue ticket is closed.