Quick answer: A bug dependency (or issue link) is an explicit relationship connecting two issues in your tracker. Common link types include 'blocks/blocked by' (one must be fixed before another can be), 'duplicate of' (same underlying bug), and 'related to' (connected but independent). Links capture how bugs relate so you can manage them as the connected set they often are.
Bugs rarely exist in perfect isolation. One bug blocks the fix of another; two reports turn out to be the same underlying issue; a cluster of bugs all stem from one root cause. Bug dependencies and issue links are how a tracker captures these relationships, turning a flat list of independent issues into a connected map. Understanding links helps you manage bugs that affect each other rather than treating every issue as if it stood alone.
Types of Issue Relationships
The most important link type is the dependency: 'blocks' and 'blocked by.' If bug A must be fixed before bug B can be addressed, B is blocked by A. This relationship matters for planning, you cannot work B until A is done, so the dependency tells you the order. Recognizing blockers prevents the frustration of starting work that cannot be completed because something else is in the way.
Other common links: 'duplicate of' (this issue is the same as another, the canonical one, which is how merged duplicates are recorded), and 'related to' (the issues are connected, perhaps sharing a cause or a system, but neither strictly blocks the other). Some trackers also support parent/child or sub-issue relationships for breaking a large issue into pieces. Each link type expresses a different kind of connection.
Why Linking Issues Helps
Links surface relationships that would otherwise be invisible and easily forgotten. A blocking dependency, recorded as a link, ensures you do not waste effort on something that cannot proceed and reminds you to handle the blocker first. A 'duplicate of' link keeps duplicates connected to their canonical issue, preserving the reporters and the count, rather than scattering them. 'Related' links help you spot that several bugs share a root cause, so fixing one might fix others.
Without explicit links, these relationships live only in someone's memory and get lost. With them, the tracker itself reflects how your bugs connect, so anyone looking at an issue sees what it blocks, what blocks it, what it duplicates, and what it relates to. This is especially valuable on a team or over time, where the person looking at a bug may not be the one who knew about its connections.
Using Links in Your Workflow
Links pay off most in planning and root-cause work. When planning an update, dependency links tell you the order to tackle things, blockers first. When investigating, 'related' links help you see clusters that might share a cause, so you can fix the root rather than each symptom separately. And 'duplicate of' links are how a clean deduplication workflow records that many reports are one issue.
Bugnet supports issue links and dependencies, so you can record that one bug blocks another, that issues are related, or that one is a duplicate of another, and see those relationships on the issues. Combined with grouping (which handles automatic duplicate detection) and labels (which group by category), links let you capture the specific cause-and-effect and blocking relationships between individual bugs, turning your tracker into a connected map of how your game's issues actually relate rather than a flat, relationship-blind list.
Bugs aren't islands, one blocks another, two are really one, a cluster shares a cause. Issue links map those connections so they aren't lost.