So having a public issue tracker reduces the number of issues the maintainer has to respond to, because it enables (certain) people to answer their own questions by looking at what has been discussed previously.
There are very good reasons for why issue tracking is now the standard for 99% of open source projects. It's not about having fancy web UIs, it's about the process itself.
I imagine the same kind of users would also use the Algolia-powered search bar at the bottom of (almost) every HN page to search for prior discussions on a topic. Even if a topic shows repeatedly over the years, Dan always replies with at least a fresh summary next to a link to prior issue - as a result, there's a really good chance you'll hit gold when you search for it.
> So having a public issue tracker reduces the number of issues the maintainer has to respond to, because it enables (certain) people to answer their own questions by looking at what has been discussed previously.
I feel it's important to recognize the limits of the analogy. HN threads are not a product. Dan is not a maintainer. People's questions and complains are not issues. Moderating a discussion group is all about human connection[0].
Now, I do believe a lot of the things Dan writes should be collected, edited, and published as an updated FAQ. I get why guidelines are vague, and why not everything is spelled out, but if the amount of repetitive moderation work it creates is keeping Dan at capacity, then maybe it's worth it to extend the FAQ a bit.
> There are very good reasons for why issue tracking is now the standard for 99% of open source projects. It's not about having fancy web UIs, it's about the process itself.
I may be too cynical, but I think the reason is mostly path dependence: this is what Github shipped with when it took the world by storm. It was both streamlining and dumbing down/functionality reduction of systems people used prior (Redmine, Trac, and then earlier systems) - but very convenient at entry level. So people adopted it, and now are used to it, and bend it way beyond its performance envelope, for things like long-term issue database or LARPing project management. Or keeping a community - issue trackers and OSS projects are too drive-by for that.
Point being, most of those reasons don't apply to HN moderation, and issue trackers are a poor fit for this in general. If we had to do it somehow, I'd prefer a meta.news.ycombinator.com board that's running Lobsters clone (because it's like HN but supports tagging threads, which would be useful here). But I feel that not doing anything fits HN better - this is a community, not a corporation; not everything needs to be streamlined. There are strong social side effects to having people just talk about things.
--
[0] - I think. Dan has much more experience and a better perspective on this.