All those things are basically like a software job, except for the part that you aren't paid.
The skills to handle it are the same.
In commercial development, you ideally have some layers between you and the customers. That depends on how large of an outfit you are and so on.
How it works at Reasonably Big Co. is that all those requests from the end users don't go to you directly but to some customer support people (who are actually technical: they develop solutions and fix issues by actual coding; do not think "Microsoft customer support" here). You, in turn, support these people: but your manager should be coordinating that. If you are asked anything that would require significant development, you redirect to your manager; other than that, you help as much as you can without derailing your official work schedule.
Secondly, if customers have some major request like for a major feature, support may defer them to "product management" to have that work put on the road-map for the next release or whatever.
Product management doesn't bug you directly to develop anything. They negotiate with your managers to hammer out what is in scope, and from there a schedule is devised and so on. You end up with some tasks out of that schedule.
Similar principles can be applied to your OSS project: you (and possibly the handful of other contributors) just have to wear all these hats yourselves.
Here is the thing: those aforementioned support people independently produce solutions to problems. They check them into their own repos and they release that stuff to customers. Then later, customers want all that stuff carried forward in the software. So there is a tension: there are all these wild and wooly patches whipped up by support, of varying quality and they (or equivalent solutions in their place) have to be somehow integrated. The support people tend to say yes to customers to make them happy which isn't always best for the product.
That is quite similar like when in OSS you are receiving complete patches from highly technical users who can code.
The skills to handle it are the same.
In commercial development, you ideally have some layers between you and the customers. That depends on how large of an outfit you are and so on.
How it works at Reasonably Big Co. is that all those requests from the end users don't go to you directly but to some customer support people (who are actually technical: they develop solutions and fix issues by actual coding; do not think "Microsoft customer support" here). You, in turn, support these people: but your manager should be coordinating that. If you are asked anything that would require significant development, you redirect to your manager; other than that, you help as much as you can without derailing your official work schedule.
Secondly, if customers have some major request like for a major feature, support may defer them to "product management" to have that work put on the road-map for the next release or whatever.
Product management doesn't bug you directly to develop anything. They negotiate with your managers to hammer out what is in scope, and from there a schedule is devised and so on. You end up with some tasks out of that schedule.
Similar principles can be applied to your OSS project: you (and possibly the handful of other contributors) just have to wear all these hats yourselves.
Here is the thing: those aforementioned support people independently produce solutions to problems. They check them into their own repos and they release that stuff to customers. Then later, customers want all that stuff carried forward in the software. So there is a tension: there are all these wild and wooly patches whipped up by support, of varying quality and they (or equivalent solutions in their place) have to be somehow integrated. The support people tend to say yes to customers to make them happy which isn't always best for the product.
That is quite similar like when in OSS you are receiving complete patches from highly technical users who can code.