Here’s a thread where you can share your favorite strategies for keeping track of bug fixes.
I have figured out that I work better with something that’s not complicated, and where I don’t have to type a lot.
So most recently what I have been doing is setting up a spreadsheet where each row represents a bug or a change I want to make. I have like 4 or 5 columns, but the two most important columns are the column where I describe the bug, and the priority column.
I try to read through a transcript in order from beginning to end, and each time I come to something I want to change, I copy-paste the relevant section of the transcript into the description cell. If it’s not obvious just from looking at the pasted text what the problem is, or if I want to remember something about it, I’ll add a little note in the cell as well.
After I go through the whole transcript, copying and pasting things, I go back to the spreadsheet and assign each bug a number from 1-3 in the priority column, where 3 is high priority and 1 is low priority. (When I fix something, I change its number to 0, because no further action is needed.)
Then I use the data sorting feature in the spreadsheet program to automatically sort the rows by priority, with the high priority ones at the top, and the already-fixed things at the bottom.
When I fix a bug and test it to make sure it works, I note in another column that it’s fixed, and I like to color the background of the rows that are done, but those things are also optional. And every once in a while, I do the automatic sort again to send the fixed things to the bottom.
I’m usually not a fan of over-engineered project management systems, but I’ve found Trello really works well for tracking testing feedback and bugs - you can lay out various columns, like “bug”, “potential new feature”, “testing needed for fix”, “done”, etc., and then populate them with cards. You can add details or even file attachments to each card, and move them between columns when you finish a task. I find it’s pretty easy to go through a transcript and jot down all the stuff I notice, and then use the system to organize my progress fixing things.
I’ve used Bitbucket bug tracking before, but for my IFComp entry I just have a text file called issues.txt with sections for “Pending” and “Complete”. Each bug gets one paragraph in the file, and I move it from one section to the other when it’s done.
I use GitHub for the main issue reporting/fixing. As Mike alluded, you don’t have to know a ton, and using too many detailed features may be a waste of time and energy.
The issue reporting there is quite nice, and I like the search feature to remind me, hey, I did that. When you commit, you can also say “I fixed #7” and that helps you track which commit fixed what.
I find a notes.txt file or [TODO: ] in the header works pretty well for minor stuff.
I put [??] next to something that is really low priority, where I don’t see an easy way to do it right away, or if it isn’t worth the time. Then I look through it again every so often.
One other neat thing about github issues is, I can set a timer every day to open up the issues page, so I always nudge myself a bit.
I have a spreadsheet template that I can just copy for each project. It has columns for location of the issue, description, priority, and status. If it’s a joint project with Encorm there’s also a column for who’s working on it.
It also automatically color-codes rows based on whether they’re high/mid/low priority and then greys them out when they’re marked as resolved, but that’s just because I enjoy conditional formatting.
I tend to make complicated spreadsheet to-do lists when I’m developing the game, but for testing I rely on my physical project notebook.
While reading through a transcript I just write down the things I need/want to change, one after the other, and then go back later to tick them off. If I tick off most of the things on a page but there’s a few tough ones left, I highlight them so they don’t get lost.
Having an updates/release notes.txt is really nice, because it reminds me that, yes, I indeed did do something since the last release, and re-releasing will thus not be a sort of attention grabbing e.g. “I fixed some typos! Spend more time paying attention to me!”
(On a related note, I have a notes.txt file for each of my projects, and I symlink them to a github directory, so that never gets lost. If I hit a block, I just scour notes.txt.) 95% of it doesn’t get used but the 5% that does is awesome.)