Jump to content

  • Help us clean up the Bug Tracker

    TriggerAu

    By TriggerAu (edited)

     Share

    After the recent pre-release, 1.1 release and follow on patches we’ve finally had some time to look back at the overall bug tracker state and look for some areas for improvement.

    There are currently about a dozen tracker projects which cover the various test teams, platforms and backlogs, and while investigating the tickets that are currently open we found ourselves wondering if we should make some bigger changes at this point in time:

    • Across all the trackers there are approx. 2700 open “bugs”;
    • On top of these are 800 feedback and feature items;
    • These tickets go back to the start of the tracker (back in 2012) and as a result a lot of them were most likely fixed, but not closed out in the trackers;

    Doin’ the Maths
    Now obviously we could start at #1 (“Docking nodes get misplaced on loading certain docked vessels”- it’s already closed, I checked) and work our way through one at a time until we have checked for duplicates, retested or confirmed and followed each one through, but simple mathematics tells us this might be a problem. If we assume it takes 20ish mins to work each of these that’s 112 eight hour days of test time, and that’s if every bug report is perfect and the steps followed don’t need any communication with the reporter to ask questions, clarify, etc.

    That would be split across multiple people in reality, but it doesn’t include triage of any new bugs, or involvement in development and testing that’s underway currently or needed in the future.

    The Painful Truth
    Hopefully many of you reading this come to the same conclusion we did: With the amount of resources we have available within the team, it’s simply not the best use of time to go through all these bugs in this way -- but we do know that there are some very good reports in there that still need to be fleshed out and worked on.

    So How Do We Tackle This?
    The idea we are working towards is to tackle this in a couple of stages:

    1. We are going to mark all open the bug reports prior to a yet to be determined date as requiring clarification;
    2. When this is done we need you guys and girls to eyeball these tickets for clarification and let us know if they are still a bug and still important;
    3. After a few weeks any bugs that have not been touched will be archived away – still there but removing a lot of noise for the producers and developers to see what is key;

    By making these changes we hope to get down to the more important issues that are outstanding and get them front and center in planning and resource allocation. We’ll also be similarly tweaking a number of test and internal projects to help sharpen our focus internally as well.

    What’s Next and What Can You Do?
    We do know that this may not be a universally appreciated idea, but we do feel it’s a lot better than some of the alternatives and does give us the chance to improve as well (it’s probably better than TriggerAu’s original “Slash and Burn Festival” idea too). 

    Before we kick this off we will provide more details about what sort of info and updates will best help us to get to grips on each bug, so please keep your [electronic] ears open.

    The involvement you all have with the tracker is massive, there are very few communities as involved or interested in the state and improvement of the games they play as this one and we do truly appreciate it. I think that together we can really clean out the ancient dust bunnies from the tracker and help clarify the key issues.

    Edited by TriggerAu

     Share
    Go to articles

    User Feedback

    Recommended Comments



    HafCoJoe

    I want to wish you and the rest of the team the best of luck with this cleanup. I'm one for tidyness (Just recently did a system wipe and reinstall of Windows 10 when upgrading processors) and I'm sure after this job is done your guys minds will be a whole lot clearer. :)

    Link to comment
    Share on other sites
    John FX
    On 11/07/2016 at 2:04 PM, TriggerAu said:

    Am writing the detailed instructions and testing in redmine, there will be a "Needs Clarification" status (or similar) and will have detailed instructions when its time to go :)

    We wanted to share the plans, before we started making changes

    When it is time please make some form of announcement (like this one) on the front page, maybe the devnotes as well, I`d hate to miss this.

    Link to comment
    Share on other sites
    TriggerAu
    10 minutes ago, John FX said:

    When it is time please make some form of announcement (like this one) on the front page, maybe the devnotes as well, I`d hate to miss this.

    Will be in the support forum and all the places we usually hang out for sure :)

    Link to comment
    Share on other sites
    jdcr

    I applaud this. Fixing bugs is what KSP needs most in my opinion. I started in 0.23.5 and while KSP is one of the best games I've ever played, my experience has been steadily declining ever since, as more and more bugs accumulated. From slightly annoying stuff to core functionality-affecting to complete breakdown which finally made me abandon the game altogether. I'd be very happy to return once I can play it without constantly being annoyed by stuff not working. Honestly, I wouldn't even be bothered if no new features were introduced (or even if some feature were to be removed) in exchange for fewer bugs. (But I know that's probably an unpopular view.)

    Cleaning up the bug tracker is a good first step. I've always felt that it was a valuable resource that's been unnecessarily ignored by the devs. Every single bug I've ever encountered in KSP had already been documented by other players and in most cases these reports have been kept updated over months and years whenever a new version of the game arrived. Sure, I've noticed some instances where players filed a bug wrongly because they didn't understand the game (or physics) and some bugs are more like feature requests. But that shouldn't keep you from taking advantage of the amazing work that people have been putting into this (and still are).

    I hope that the cull will make the tracker more manageable for the devs. Although I have a slight feeling that perhaps KSP just does have that many bugs. That's just my very subjective impression though. Anyway, I wish you all the best for your work!

    Link to comment
    Share on other sites
    bewing

    bewing 3,122

    Posted (edited)

    I have been going through a few ancient bug reports over the last months and marking some resolved -- marking others as "still present in 1.1.3" in the comments. The problem is that some of them are very system specific. Graphics effects that only appear on Macs and Linux are things I can't test or verify. If you want to spend some bughunting time efficiently, then you should concentrate on the ones that only you have the ability to test.

    Many of the bug reports are marked as "resolved" in the comments by the authors of the bug reports (because they did not have the ability to close the issue themselves at that time). If you guys would just cull those ones out in a preliminary sweep, I think that would reduce the count a lot.

    One suggestion that I would make is that the voting system has only been implemented recently. That means that any bug that has votes is one that still exists. That would give us an easy way of marking bugs that are still around. If you would just make some explicit policy about votes. Either votes mark bugs that still exist, or votes add urgency to a particular bug report. And then Anquietas and I can go mark a lot of stuff.

    In some sense, we need some feedback, though, on which bug reports have even been looked at. As said above, some of them have been sitting there for 4 years, and don't have a single comment by a dev. If they have been looked into, but seem to be too hard to fix at the moment -- even knowing that is better than silence.

     

    Edited by bewing
    Link to comment
    Share on other sites
    TriggerAu
    10 hours ago, bewing said:

    I have been going through a few ancient bug reports over the last months and marking some resolved -- marking others as "still present in 1.1.3" in the comments. The problem is that some of them are very system specific. Graphics effects that only appear on Macs and Linux are things I can't test or verify. If you want to spend some bughunting time efficiently, then you should concentrate on the ones that only you have the ability to test.

    Many of the bug reports are marked as "resolved" in the comments by the authors of the bug reports (because they did not have the ability to close the issue themselves at that time). If you guys would just cull those ones out in a preliminary sweep, I think that would reduce the count a lot.

    One suggestion that I would make is that the voting system has only been implemented recently. That means that any bug that has votes is one that still exists. That would give us an easy way of marking bugs that are still around. If you would just make some explicit policy about votes. Either votes mark bugs that still exist, or votes add urgency to a particular bug report. And then Anquietas and I can go mark a lot of stuff.

    In some sense, we need some feedback, though, on which bug reports have even been looked at. As said above, some of them have been sitting there for 4 years, and don't have a single comment by a dev. If they have been looked into, but seem to be too hard to fix at the moment -- even knowing that is better than silence.

     

    Some good stuff in there @bewing. For some extra detail from me (now that its the weekend and I got some time):

    • I've drafted up some detailed instructions that will be shared with the test teams later today to check I haven't messed up entirely :P.;
    • We'll use a status change to indicate whats still there or whats not.
    • Do want to use the votes system more effectively, but its visibility is not as good as it should be (its actually been there for a long time, but its not obvious enough) - you have to add the column and right click to vote on the list in the public tracker - I think its a permissions thing and is on the list to look at.
    • I do want to try and do another pass through the tracker to reduce noise as well before we kick into gear and its a great reminder

    Thanks

    Link to comment
    Share on other sites
    Violent Jeb
    On 7/9/2016 at 0:28 PM, diomedea said:

    We have no gain at all from all the time spent testing KSP. Notwithstanding that, I'd be curious to see you first buy other 5 copies of KSP, may be that is all we need.

    I'll never buy another copy first regardless of what is promised second. I got burned on that one before. Now, console players are reaping the benefits of those promises, in my humble opinion.

    Link to comment
    Share on other sites
    bewing
    On 7/15/2016 at 6:25 PM, TriggerAu said:

    Some good stuff in there @bewing.

    If you liked my previous suggestion, maybe you'll like this one too. If we could somehow make one great big checkoff list of bug reports, which indicates that at least ONE bughunter has looked at each report closely -- that may be very helpful in reducing duplication of effort. Something we could edit ourselves to indicate we had looked at one of them.

    And as far as feedbacks goes: you should print them all out on some paper to use for ideas for upgrading future versions of KSP, and then remove them from the bugtracker (probably by marking them 'Acknowledged' -- the way many were done during the pre-release.) At the moment they add a little too much clutter to the bugtracker, and you have to pay close attention to what is a feedback vs. bug report when scanning the list by eye.

     

    Link to comment
    Share on other sites
    PickaxeforKerbalssss

    Ive been having a problem with the game loading like, when the LV-T30 engine comes up on the loading part, the loading just stops in its tracks! Can you work on fixing this bug on Kerbal Space Program?? ;.;

    Link to comment
    Share on other sites
    robertr4836

    I'm new to KSP and there are two bugs that I find very bad for gameplay and from looking for solutions it seems these two have been known for years (but not fixed??).

    1) Docking ports sometimes "stick" (as in sometimes you click "undock" but the two ships remain locked in an eternal, unbreakable embrace).

    2) Cloning or what I like to call "ghost" Kerbals.  When you EVA and try to re-enter the vessel but a clone or ghost Kerbal is left clinging to the outside of the ship (preventing time acceleration and causing other problems until the system crashes or you get frustrated and revert to an earlier save).

    Link to comment
    Share on other sites
    Shulong Zhao
    On 10/07/2016 at 0:15 AM, AlmostNASA said:

    Poor Danny2462 basically this post is his whole KSP bug life wasting away. Poor Danny..;.;

    But when more updates come out there will be more bugs

    Link to comment
    Share on other sites

×
×
  • Create New...