We had hoped to have a bug-tracking system for you to use with this course, but it wasn't ready in time. In lieu of that, we're asking you to keep track of bugs in the BUGS directory within your project.
Each bug (or to-do item; see below) should be in a separate file, which should look like the following:
Summary: one-line summary of bug Component: which part of your project contains the bug Severity: how severe: critical, major, normal, minor, trivial Milestone: what's the deadline on fixing the bug Owner: who's responsible for fixing it
After these five lines, you should include a longer description of the bug, ideally including instructions on how to reproduce the problem.
Following the description, you may wish to add notes to the bug report, as you investigate the problem and determine its cause, or as you discuss potential solutions with your partner. (Having records of these discussions can be very helpful in the long run, as you try to remember why this particular piece of code looks like it does, or why you made certain design decisions.)
Once you have resolved a bug, you can move it into the BUGS/closed directory, so you don't have to filter those bugs each time you look at the database. For example, to move the startup-crash.txt bug into the closed directory, you would execute the following commands from within the BUGS directory in your working copy:
An important note: while the directory is called BUGS, the contents can be more general. Many industrial developers consider bug-tracking systems to be sophisticated to-do lists. So, for example, you could put feature requests in your BUGS directory. Indeed, many development teams require developers to start a new project by opening ``bug reports'' that describe the functionality they intend to implement for that project. When the implementation is complete and tested, they close out the bug report.