zlacker

[parent] [thread] 2 comments
1. TeMPOr+(OP)[view] [source] 2023-04-06 07:55:01
> I can't imagine not being able to just write "Duplicate of #3845" and close the issue.

You know that what you're saying is "I can't imagine not being able to show the user a middle finger?", right? Because that's how it usually feels on the receiving end. You mentioned StackExchange upthread; the identifying meme of SO and SE family is "closed as non-constructive" and "closed as duplicate" - that is, how absurdly many good topics are killed or blocked this way for no discernible reason.

For Dan, I imagine the amount of work is the same. He could be clicking[0] to close ticket #12346 as duplicate, and making it clear to the entire HN userbase that user 'TeMPOraL just wasted his time by having the audacity to ask question without first searching[1] through prior #12345 issues. Or, he can just make a few keypresses to insert a canned paragraph into an e-mail[2] - resulting in me getting my answer/scolding directly into my inbox, but more importantly, in me feeling heard and respected as an individual contributor, as well as being reassured HN is moderated by someone who cares. Not to mention, I can always reply if I believe I'm being dismissed too early, without risking to create a stink.

Same amount of work, completely different outcomes.

--

[0] - In some crappy modern issue tracker WebUI. Like the GitHub one you mentioned. Or Gitlab.

[1] - Via some crappy, eventually-consistent Elastic Search-backed search form.

[2] - Or, these days, he should be able to forward the e-mail to DanGPT, with an annotation like "doesn't work, gtfo, hash table in the sky", and DanGPT would then produce a few polite and informative paragraphs, based on the forwarded e-mail and maybe automatically pulled comment history. I wouldn't really mind to be on the receiving end, even if I learned this is how the reply was written. It's still much better than "Closed as duplicate" or "WONTFIX" or "LMGTFY".

replies(1): >>p-e-w+M
2. p-e-w+M[view] [source] 2023-04-06 08:05:33
>>TeMPOr+(OP)
Except that it's not the same amount of work, because many issues/questions are in fact duplicates, and many users do in fact search the issue tracker before filing another one.

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.

replies(1): >>TeMPOr+Z2
◧◩
3. TeMPOr+Z2[view] [source] [discussion] 2023-04-06 08:26:38
>>p-e-w+M
> and many users do in fact search the issue tracker before filing another one

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.

[go to top]