Ben I'm struggling to establish a clear understanding of the life cycle of an issue. Consider https://gitlab.haskell.org/ghc/ghc/issues/15872. Here is my faithfully recorded chain of thought at 2330 on a Tuesday night. * I can see that it is closed * But I wonder if it was fixed? * Well, scrolling up from the bottom, apparently it was mentioned in no fewer than six patches. That's odd. Why is this issue mentioned in six patches? * Oh, one of those six patches is a dup, mentioned twice. No idea why. * Are any of the five The Patch that is designed to fix this issue. Indeed does The Patch exist at all? And what MR is it in? * Oh, what is that MR? * Hmm. Well Ryan says "I've opened MR 851". Maybe that's it? * Let's head over to MR 851: https://gitlab.haskell.org/ghc/ghc/merge_requests/851 * Oh! It just says "Closed". I was hoping it'd say "merged", but no. * Uh oh. Near the top it says "Closed by Omer"... "the changes were not merged into master". * Then scrolling further down there is a lot of noise from Marge, followed by a presumably hand-written message from Omer saying "Merged as cc495d57.". * Huh. So maybe it did get merged after all. You can see how confused I am. It all just feels like much more work to find relevant info than it should be. It's frustrating because all the info is in the system, -- it's just hard (for me) to find. An issue should say prominently: this is The MR (or MRs) that fixes the issue. It should be easy to tell if those MR(s) have been successfully merged - along with their commit messages (this will come Moe Bot). Trac used to let you close a ticket as "fixed" or "wont-fix" or "invalid" etc. This was Jolly Useful. Doesn't Gitlab? Similarly, MRs sould be closed as "merged" or "abandoned". Much of this is not under your control - it's what GitLab does. But maybe we should have stronger best-practice guidelines. Eg "Never just close an issue; always say "Closing as won't fix" or...". etc. Simon