Lit Review, Bug Reports
I recently read Simon Tatham’s small article “How to Report Bugs Effectively” (https://www.chiark.greenend.org.uk/~sgtatham/bugs.html) In this article Tatham explains how everyone should go about submitting bug reports to any form of programmer. I feel that he made quite a few good points that I will definitely be paying closer attention to for any future bug reports I make. The main thing that I found me thinking I might have failed to do in the past was describing exactly what actions I took to get to a certain state of the program; More specifically, rather than saying “I selected option X” you should instead specify if you simply clicked on the option in the menu or used a shortcut to select that option. Two other things that I personally have tried to stick to in the past that he also mentions are, giving the programmer some way to recreate the bug themselves and giving them a step by step guide to hopefully recreate the state that you had along with, actually being helpful while explaining the bug rather than simply saying “It doesn’t work.” and instead giving a detailed explanation as to what the bug actually is and what could be the possible causes. There are a few things that I feel might still be important but, less so than the others. For example, I do feel like system specifications like screen size as Tatham talked about in the article. I feel like these details should only really be given to the programmer in relative situations like the UI for a game overlapping or something similar, or if the programmer specifically asks for that information. Otherwise, this information is probably useless and just makes it more difficult to look back through the bug report when looking for specifications when what you need is grouped with another 5-6 specs that you don’t necessarily need. The other things I didn’t necessarily care for in the article were the two sections labeled “I think the tachyon modulation must be wrongly polarised” and “That’s funny, it did it a moment ago.” While Tatham does bring up some things that can be annoying in bug fixing I feel like he contradicts himself in one and the other is unneeded in a way. (Besides the one part that I mentioned earlier in this post.) In the “..tachyon modulation..” section he talks about I guess ‘prescribing’ a solution to the bug in the report which to me seems to go against what he said previously where he encouraged suggesting what could be causing the problem. And with the intermittent bugs section I feel like he simply just states that ‘sometimes bugs happen and sometimes they don’t’ but in a very longwinded way. The exception here being that he points out it may be due to a discrepancy in the user and programmer’s setups, although I feel that that point could be made in another section of the article. Overall, it’s a helpful guide to the basics of bug reporting but most of it seems like common sense to me and makes me wonder why he thought that a large piece of writing like this was necessary?