Kerbal Space Program

h1. 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)

h2. People Involved

There is a team of testers and other interested people, hard working volunteers, who look through these bugs and to assist people who have issues, as well as helping to identify when bugs need to be raised to the attention of developers. These volunteers are experienced KSP players who give their valuable personal time to assist other players of the game. Please be respectful of these peoples commitment and keep in mind that the better and more 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.

h2. Triage/Confirmation

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

# 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.

# 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

# Adding any extra detail - In this last part of triage we might be adding some details around any missing categories, version specifics, etc

h2. 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

h2. 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.

h2. 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.

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