On 27 May 2022, at 06:01, Attila Pinter <adathor@protonmail.com> wrote:

Users on the other hand IMO shouldn't interact with developers directly. FOSS projects seen the issues with that and continue to suffer that burden. I would keep developer communications separate from user space, for example I wouldn't bridge the KDE IRC with the Telegram openSUSE group, but would bridge it with say the Discord or Telegram KDE group for contributors to easily interact with each other.

There’s a core problem here, which has been outlined by Jim: the userbase of linux systems has changed from tech-heads to normal people, and so the volume and type of problems / questions (issues) to be addressed is changing.  Our processes for addressing user issues haven’t changed.

If this flow of issues lands on the developers they get no or little development done.  If non-devs answer then there are (occasional or frequent) defective or biassed explanations or fixes. If devs don’t get constant feedback from the users of their software, then the gap widens between what the devs think is good software (and so where they focus their limited time) and the users’ view of the same.  If the process or organisation isn't clear then the outcome (for all) is totally unpredictable - self organisation only works when there is a shared view of goals / objective and values.

One of the most powerful “learning experiences” of my early career was working for 2 years on what was, at the time, called first line support.  My viewpoint and standards for “quality” software and services changed radically and permanently.

The latest iteration of solutions to be adopted in the commercial world is DevOps, which only works, when there are non-expert or a high volume of users of a system or service, if there is a different group who interact directly with these users.  This group can be other forum (or mailing list) members or a team of support people (often non-expert & following a script).  Increasingly, larger organisations are trying to use automation (chat bots) + expert maintained FAQs to address this need from the less expert service users.

What’s needed for this to work:

1. simplicity for the users of the software / service - inexpert people must know where to go to get an answer to their (often trivial) issues

2. efficient - low overhead for the devs while maintaining feedback - they need to know where they should spend their time to provide maximum value for them and the community

3. quick & accurate - people want a solution to their issue now, and first time.  This is valuing their time as well as the devs’.

4. recognition - there is value to all of us in “someone” (aka volunteers) using their time to keep our users happy and taking a load from the devs (other volunteers).

I don’t have an answer (if I did I’d be selling it through consultancy to big organisations :-) ) but I think we, the openSUSE community, have some mismatches between the outcome we want and the processes (informal or not) we’ve set up.  [The technology we choose often implies a process and organisation.]

This may look to be off topic or an over-elaborate answer to a simple question, but I think that we can’t answer the question without considering the underlying process and organisation.

Just my $0.04 worth
David