SEPARATION OF CONCERNS IN A BUG TRACKER

Summary from the TLDR Web Dev newsletter

Many bug trackers conflate factual information about bugs with plans and intentions for fixing them, leading to awkward data representations and difficulties in querying specific properties. A better bug tracker design would separate these concerns into "facts" and "plans" tables, linked but distinct. The "facts" table would record objective details about the existence and severity of bugs in the code, while the "plans" table would track intentions, timeframes, and priorities for addressing them.