Even as a developer, an issue from anyone (even non-technical people) helps people find out quickly if someone else is having the same issue you are with something, even if it's not fixed.

Yes. As a maintainer whom actually cares about feedback and usability, I care that features developed apply to the real world and aren't imagined in an utopian vacuum by own possibly insane biases. Social democracy, not authoritarianism. If code isn't usable by other people in the real world, it's just graffiti while waiting for Godot.

As a maintainer who also cares about feedback and usability, but who doesn't maintain any high-traffic projects, I can just about imagine how frustrating and destructive of motivation it gets to see the same no-thought issues raised over and over and over.

But if you close them NOTABUG or WONTFIX, you get a reputation as that guy who just doesn't want to hear about it, what a bastard.

I think there must be a middle way somewhere, for those projects which attract a lot of interest but few or no co-maintainers. But I'm glad I'm not on the hook for finding that middle way, too.

Oops, hit logout on that throwaway account. Bye-bye, religious flame wars. ;)

Support is what it is, and it's a two-way street.

Most engineers usually don't have customer support or sales experience, and so don't have the experience to triage and communicate pro-socially. (I sold software as a high-school job and also had my own consultancy at 17.) It's important to push outside one's comfort-zone when young (or old) to acquire skills that will be vital later on.

Post the policies, requirments and desires in contributing.md promenently. (I think a CoC is redundant and tyrannical SJWing.) Setting expectations and not making promises is important.

Finally, there is a cost to FOSS on both supply and demand sides. I just had some company fork the repo of a project I fixed, make a pointless PR and then offer no contributions in a grsec-theft-style way.

PS: Subversion has a great talk about defending the community.

For this, I've seen several large projects push discussions to discourse or stack overflow, which are much better-suited mediums for discussion IMHO.

I do not like to have discussions in chat because of how unstructured they are. Important details get lost and can never be hard to recover. Furthermore github comments are an excellent place for seeing different aspects and workarounds for an issue that has not been fixed. They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way).

While chats can be used for that, they do not make a good job to archive the results a group discussed. For open source projects, this is essential. I often read 1 year+ old issues and they discussions are still accurate and good.

When people chat, they do not have a lot of discipline to document this. Chats are more like a conversation. They are great for two or more people to discuss something but not really good for an outside person who just gets to read the protocol.

SO is not the place to have discussions. You help people for their specific problems. You do not discuss changes there. At best, you leave a link to the issue tracker which deals with that topic.

Who said anything about chat? Parent was talking about https://discourse.org which has effort put into archival / finding old discussions

> They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way).

Is this not literally the point of comments in the code?