[folex]

While the idea is good and kind, it's not as easy as it seems.

That's called a support line, and it requires good understanding of the project by non-dev support. That requires to educate someone about your project, and maintain their knowledge to be up to date.

That's not an easy task even in commercial projects with a team of several people, and ability to delegate, and requires a non-trivial skill of leadership.

In other words, the project is very lucky to have such people. And while it sometimes happen organically, it's hard to implement this intentionally.

[shittyadmin]

They don't necessarily need full knowledge of the product or any such thing, they just need to be able to provide a sort of filter, remove anything uselessly abusive or congratulatory without value, open defects for obvious bugs with reproduction instructions and get users to dig in and provide useful details when asking questions.

Those questions can then be answered directly by them or forwarded off to a dev who will have more detail and be able to get answers faster without the drudge of dealing with the rest of it.

Personally while working at a small company and doing both support and development work, I found it helpful to simply tell customers we'd address issues "with the development team" even when that meant I was going to work on it. Drawing that line in the sand between support and development roles compartmentalize those activities and reduces the immediacy of demand from users.

[rossdavidh]

I'm sure it's not easy, but... 1) a support line offers support to the end user, which is different; I'm talking about filtering out the emotion from the content 2) most people who could do this, do not know that they could, that there is a need, or how one would volunteer to do it 3) the same person would not have to process all feedback, just as much as they have time for; at least some of the pile of feedback would be processed by someone other than a dev 4) the non-technical nature of the person is actually helpful, because that is usually where the originator of the feedback is coming from, and the job of this person would not be to determine the fix, but only to separate content from emotionally motivated criticism

[fjp]

I have help multiple roles that could be called "very technical support" - technical enough to understand the guts of a project, troubleshoot, deflect reports that are just user error, report bugs on behalf of users with extra debugging insight, etc... but not technical enough to contribute meaningfully to the source code.

That job is just as exhausting and unrewarding as any support role. There's no fucking way I would do it for free on open source software that wasn't my own creation. EDIT: Unless it was a definite path to being a core contributor to a project I was very passionate about.