I agree that a blanket ban on necro-posting has the negative consequences you mention. It is commonly discouraged as a heuristic, because necro-posts often have a high time cost to those who were previously involved. First, because by that time they've forgotten the context, and since the new post often does not summarize the entire previous conversation, it forces someone who wants to make sense of it to go back and re-read it to understand that context. In contrast, a new issue is more likely to stand on its own and be easier to process. It can still link to the old issue in order to keep the chain intact. And second, because the new commenter is often wrong that their bug is the same, or has missed some of the context and is just adding duplicate information. Note that both of these apply more to long threads.
I think this suggests two things:
1. There is an opportunity for better tooling. I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url). Imagine that but with any bug that's been marked as a duplicate (which the bug reporter should be able to do). Now you get the best of both worlds -- a way to view the new post with or without context.
2. Necro-ing would be less problematic if bug tracking were less centralized. More long, support-type bugs between distributors and users, where is preferable to log a new issue than necro an old one; more short summaries of confirmed bugs submitted by maintainers to the upstream repo. GitLab's separation of issues and epics is a good idea here, although their implementation is awkward at best.
> And second, because the new commenter is often wrong that their bug is the same, or has missed some of the context and is just adding duplicate information. Note that both of these apply more to long threads.
That's a good point I haven't considered. Yeah, the consequence of mistakenly starting a new topic under an unrelated old thread is that the new discussion is now miscategorized and harder to find.
> It can still link to the old issue in order to keep the chain intact.
Yes, that would be great. If one could pull off an UI that nudged people to correctly link back to older threads, so that such links were typical, I think it would mostly solve the necropost problem - the etiquette could be changed to "don't necropost; if starting a new thread on a topic that was discussed in the past, ensure your post links back to those old discussions".
(I think I saw a few boards automatically generating a box with "related topics", but IIRC, their method of finding related topics yielded lots of false positives. If improved, this could work too, though I would still prefer explicit links that don't change over time.)
> I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url).
I personally don't want that. I hate this UI pattern. In particular:
- As implemented on social media platforms, it makes it nearly impossible to find your way back to something you saw a minute ago but scrolled past.
- As implemented on news sites, auto-appended articles are usually not relevant to the one you just finished.
- The URL substitution is particularly annoying - usually, the time I care about the URL is when I read/skim the article to the end, and then decide to share or bookmark it. At that point, the URL will already be changed to point to a different article, and it's easy to miss. And the way these feeds are implemented, if you follow the link to a follow-up article and scroll up, you won't get back the article you actually wanted.
I think this suggests two things:
1. There is an opportunity for better tooling. I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url). Imagine that but with any bug that's been marked as a duplicate (which the bug reporter should be able to do). Now you get the best of both worlds -- a way to view the new post with or without context.
2. Necro-ing would be less problematic if bug tracking were less centralized. More long, support-type bugs between distributors and users, where is preferable to log a new issue than necro an old one; more short summaries of confirmed bugs submitted by maintainers to the upstream repo. GitLab's separation of issues and epics is a good idea here, although their implementation is awkward at best.