This quoted section on its own makes it sound like Dan is complaining about all the people who aren't discussing the thing he (the creator of the tool/library/idea) wanted them too. I thought the same thing as I first read this section. But I think it becomes clear that he's not making that complaint, or at the very least, he describes a clear reason why people tend to discuss certain concepts, and offers a way to try to get your concepts discussed.
I disagree, I think the article was very lacking when it came to actually offering concrete advice to address the situation or, at least, was very obtuse in the giving.
To have a focused discussion on Thing X, ask for a focused discussion. The scenario he stated (discussions on the README getting picked up and whitespace preferences being spun into a mini-holy war) is just... it's going to happen unfortunately. But that discussion wasn't one the author initiated for feedback, it was a general comment thread on the repository. If you, as an author, want to spark an intelligent discussion on your product than do just that, present the points you want to debate while allowing some freedom for that noise since it isn't always useless.
Instead of: "Hey HN, I just wrote a badass new streaming protocol" and linking to the github source, specifically mention your concerns about continuing to rely on TCP for video streaming and the buffering lag it induces, link to a blog-ish thing which links to your source but frames a number of questions or doubts you have around your project if you, indeed, are at a loss and want to turn to the internet as a whole to try and solve them.
Basically, as I do in my workplace, refuse to let your discussion/meeting/whatever become a vaguely directed waste of time - set a clear agenda (i.e. a set of specific points in a blog post) to help funnel the discussion toward the useful parts. In the resulting chatter you'll probably get some whitespace criticism (spaces are simply poor manners, #tabs4lyfe) you'll get some chatter about your question (and on HN that'll be floated to the top) and you might get someone who dug behind your question and found that - yea TCP is bad, but if you're going to use UDP you'll need to have some solid check-summing in place which your project currently lacks.
So, you need to direct the discussion, but allow noise, without noise you'll eventually settle the discussion into a local maximum of functionality where everyone is nodding and saying "Yup we did it, it's not a solvable problem but we've clearly come up with the best partial solution."
I actually think your suggestions are perfectly compatible with a charitable interpretation of this article.
> Instead of: "Hey HN, I just wrote a badass new streaming protocol" and linking to the github source, specifically mention your concerns about continuing to rely on TCP for video streaming and the buffering lag it induces, link to a blog-ish thing which links to your source but frames a number of questions or doubts you have around your project if you, indeed, are at a loss and want to turn to the internet as a whole to try and solve them.
That sounds exactly like an example of Dan's suggestion to "tell a story."
But my suggestions actually offered a story indicating what was wrong in a (hopefully it was sort of off the cuff) clear manner. I found the article to be lacking a clear demonstration of what was wrong and specifically actually lacking a clear solution.
What I stated above wasn't what I read in the article, it was my proposed solution to what I discerned the issue to be.
