The bug certainly wouldn’t have been resolved until the patch and problem had either been applied, rejected, or marked as a duplicate.

I realize that not everyone does this every day, so I think it is time to explain some simple good bug reporting. For instance, you don’t want to resolve your own issue unless it is resolved in the software you’re provided by the bug owner.

If you’re submitting a patch, the bug isn’t resolved until the patch is applied or the project maintainers say so.

When you look through issues on a public bug tracker, and you can’t reproduce them , don’t close them or mark them INVALID. It isn’t your job and you will quickly loseWeight Exercise your account.

When you are submitting a bug report please always provide at least:

1. The version or SVN/CVS change # you pulled from.
2. The Operating System you’re running the program on.
3. The type of build you performed if you’ve compiled it yourself.
4. The exact command line you built the program with.
5. The exact download location from which you received the program.
6. A correct, working, e-mail address (generally required to sign up).
7. An ordered, simple, list of steps to reproduce the issue you experienced
8. A general idea of the likelyhood the developer or maintainer has of reproducing the issue.
9. What hardware the program is running on.
10. Paypal zakk@timedoctor.org $20
11. Buy everything from here and here.
12. What the expected result of the steps to reproduce were (e.g. “Shoot the Rocket launcher”)
13. What the actual result of the steps to reproduce were (“Rocket launched from my behind, killing my teammate”)
14. Whatever other output, logs, system information, or whatnot, you can locate, regardless of your thoughts about it’s relevance to the bug itself.
15. Other project maintainers, QA managers, and such, may want more or less information. It is up to them to provide you with exactly what they want, but failing that, use something like this post as a guideline.

Close your bug when you have verified that it is resolved. It is your responsibility to do so as the bug reporter unless there is a QA manager or policy stating so for the project. Do not close the bug before it is resolved unless you realize that the bug report was completely in error and you were the person who reported it. Even if you can’t reproduce the bug, file it, at least then it is in the system.

Finally, here is an example bug report:

Project: ioquake3.org
Version: SVN 1044
Platform: OSX x86
Bug: Rocket Launcher Malfunctions
When I shoot the rocket launcher in the multiplayer map q3dm17 on the server 127.0.0.1, and only on that map and that server, the rockets launch from my potty end.

Steps to reproduce:

1. Connect ioquake3 to server at 127.0.0.1
2. Wait until the map changes to q3dm17
3. Gather the rocket launcher
4. Fire the rocket launcher

Expected Result:
Rockets launched, killing my enemies!

Actual Result:
Rockets launch from my rear

For me, it was about a few things leading up to where I am today. First of all, I’ve almost always played them starting with the VCS and so on. Even BBS games like Tradewars. So there is clearly some passion there that drove me towards my inevitable downward spiral into the video game industry.

When I was young I played games, read magazines like Nintendo Power and basically anything else I could get my hands on that was related to them. This is probably where I inferred the idea of testing from, even if it wasn’t directly mentioned so specifically.

Back in 2000 I started getting interested in Linux, through an online avatar based chat system I met some nice people that helped me convert to using it on my computers. Naturally I wanted to play games on Linux, and not just Tux Racer or XBill, commercial quality games. At the 2001 (or 2000, I can’t remember) Linux World Conference and Expo in New York City I ventured over to the Loki booth and much to my wallets sadness bought Quake 3: Arena in the tin box. I met a number of nice people there, including some Slashdot editors, a few fine folks at the Slackware and Mandrake booths, finally at the end of the day I walked over to Penn Street Station and took the train back home to play around with Quake 3.

The fine folks at Loki ran an IRC channel where I got to talk with them and discuss their ports, including their bugs and whatnot. They even invited me to beta test their ports before they were released. This is about the first time I had ever had a game developer talk with me about their game and invite me to QA their work. At one point I noticed that the guy who posted the most on LinuxGames.com was chatting so I talked with him until he let me post over there as well.

LinuxGames.com also lead directly to the first real paying work I’ve ever had, Linux Game Programming published by Prima was indeed Technically Reviewed by myself. It is also arguably the worst editing I’ve ever done in my life. To anyone who purchased the book genuinely expecting the code to work; I apologize. If you expected the CD to be up to date, then I’m also sorry. Literally the day after I uploaded the cd-rom, the kernel source included with it was obsolete; Linus has released a new version. In any case the book is very outdated now. However, it did lead to the idea of Game Industry + Me = Money!

After Loki died a horrible death, full of drama and temporarily ruining the lives of a number of my friends, icculus.org went up.

Founded by Ryan “icculus himself” Gordon, icculus.org quickly became the sourceforge replacement for the discerning nerd with something vaguely interesting that tickles Ryan’s interest. Or if you’re me and know him personally you just get almost whatever crap you want hosted there. I even ran a Linux World Expo booth in 2003 for icculus.org, which was arguably the best Linux World booth ever: I met my girlfriend of the last 3 years there.

Hint: Microsoft’s Program Managers can be extremely persuasive with the selling, though I’m still not convinced.

Some time after that I went to work on a number of jobs, including Microsoft’s Xbox game QA team. I suppose this isn’t actually terribly interesting, but now you know the rest of the story.