This is a sort-of sequel to my post on my theorised Game design stack, covering how I feel is the ideal way to handle bug reports and feature requests during development of a game.

My original stack had five layers, with responsibilities divided between technical and design teams. However, I had to add both a sixth layer and a new team, testing and testers respectively, for this post. Again, there is no real reason why a person can't be on the technical, design and testing teams, as long as they handle their roles separately. There definitely should be some people on the testing team who are not on the other teams though (ie, the general public), so they can give an unbiased opinion of the game.
 
This post is on how I think bug reports and feature requests should be handled in a game design project.
 
My definition of a bug is an unintentional negative effect in a program. This could be a bug in the design (example: The level can't be finished because exit point was added behind a wall) or in the underlying technology (example: The game freezes occasionally). Note that not all unintentional effects are bugs. An AI that uses more effective strategies then the programmer had predicted, for instance, could not be considered a bug unless it has a harmful effect on the gameplay experience.
 
My definition of a feature is simply an element of the program. Again, it could be something in design (example: An art asset, or a character interaction script) or technology (example: The graphics renderer).
 
In general, feature requests are made when something new needs to be added, bug reports are made when something that exists needs to be changed. Feature requests and bug reports exist in an 'open state' by default, are shifted to a 'closed state' when they are dealt with, but can also be shifted back to an 'open state' if the bug or feature wasn't adequately resolved. Both feature requests and bug reports should also contain notes and history.
 
At each level, bugs need to be dealt with first, otherwise the project will become more and more unstable. Features should only be added when the number of open bug reports is exactly zero. I recently heard of an MMORPG being developed commercially that was briefly playable but is now unplayable as more features are added; why should it have ever been allowed to lapse into an unplayable state for any significant length of time?
 
Though in reality this ideal probably unattainable; for instance, should trying to fix a minor display glitch delay the addition of a major core feature? Perhaps prioritising bugs and features would be a workable compromise (Critical features are added before moderate bugs are fixed, but only after critical bugs have been fixed).
 
Bug reports and features requests only flow in one direction: Playtest team -->> design team -->> technical team
 
The playtester passes his requested features and bug reports to the design team. If the bugs are with their design, or they can implement the features with their existing tools, the design team deals with it themselves. Otherwise, if the bugs are with the underlying technology, or they can't implement the features with their current toolset, then they are passed to the Technical team.
 
Suggestions could made in the opposite directions. For instance, someone on the technical team could inform a designer that he can program a realistic Rain effect, and suggest the designer implement this in a level. But these should not be formally submitted and tracked requests (Unless the technician was acting in the role of the play tester).