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."
Re:Name It, and They Will Come
by yellowapple on Monday March 25, 2019 @08:03PM
(#19487982)
Maybe Dan should've told a story instead of leaving HN room to bicker about his vague "solution" ;)
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.
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."