What are best practices for linking Bugs and Epics?

[Bar T]

I use Epics to group large bodies of work for a given release (includes stories, tasks, and critical bugs).

The team has started linking all bugs to Epics, which makes it harder/longer to close an Epic.

Do you link Epics to all bugs or just a certain priority?

After a release (ie, Settings page) , do you create a new Epic for that feature/release and group the work there? (ie, Settings page additions/improvements)?

[Jack Brickey]

This is really a subject topic. It comes down to whether you feel an Epic (product?) can be considered complete if bug exist. Keep in mind that when SW is involved bugs will always exists so at some point the Epic needs to close. The other question is will an epic consist of multiple releases of SW? In that case, for sure bugs should be part of the Epic. In most cases I would say that bugs should be linked to the stories that are part of the Epic and you could use "blocks" for bugs that block the Story from being consider releasable and "relates to" to those that don't block the release of the feature. You can then use JQL filters to know when a Story is complete. Ultimately, when you are ready to consider marking the Epic done you should consider moving any open linked stories out of the Epic maybe into a subsequent Epic.

[Amit Kumar]

Absolutely, I would agree 100% to @Jack Brickey & @Joe Pitt 

Bugs are related to implementation details for a Story. Epics are representation of large blocks of Feature(s) in the Product. A epic/feature can be called complete with Bugs. Hence, we link Bugs to Stories

[Joe Pitt]

In my mind, bugs are in code so I would link them to the user story the code handles.  

[Paul Charlton]

I know this is a bit old, but curious -

If you find a bug on a story that has long since closed, or a bug that doesn't have a story.  Would you create a story for that bug to link to?

[Jack Brickey]

I would simply link the bug to the epic as a relates to