[onlypositive]

And the eventual "pull requests welcome"

[pixelatedindex]

I’m curious about what’s the best way to go about gathering user feedback and feature requests. You can’t develop a product for people to use behind closed doors, because you run the risk of building the wrong product. Conversely, if it’s too out in the open then anyone and their parents might have suggestions to improve which will drag you away from the core thesis of your product/PMF.

I guess another way to ask my question is - is the aforementioned sequence of steps (please add X, string of +1s, PRs welcome, etc) a bad thing?

[monk1]

> I’m curious about what’s the best way to go about gathering user feedback and feature requests.

IMO, building in the open is still the best way. But to ensure that you don't end up with a mongrel of a thing that tries to do every single thing requested by everybody, It does help to have a rigid set of goals about what we want to build. And the courage to say NO to feature requests that stray too far from the original design goals.

[kaba0]

I believe the latest Rich Hickey talk ‘Design in Practice’ might answers your questions in detail - I haven’t seen it recently, but it says something along the lines of don’t build features because they were requested, but instead ask why were said features requested, what’s the reason behind that and solve that problem.

As every Hickey talk, I can only recommend watching the whole thing, it is not clojure-specific at all if that were off putting for you.

[H8crilA]

The answer is you grow up, make decisions "behind closed doors" and live with the consequences.

[chrisjj]

> You can’t develop a product for people to use behind closed doors, because you run the risk of building the wrong product

Then again you could develop a product behind doors despite the risk of building the wrong product ... :)