Re: Project to improve Debian support model

[Katy Tolsen <2ndlifekaty@gmail.com>]

On Sat, Oct 21, 2017 at 9:40 PM, Paul Wise <pabs@debian.org> wrote:

On Sat, Oct 21, 2017 at 8:58 PM, Katy Tolsen wrote:

> I thank you for your time and will be interested in hearing any thoughts or
> concerns, and would happily welcome any interested parties to take any role
> they like in the design and implementation of this project.

While reading your proposal, I was reminded of this project:

https://debug-me.branchable.com/
https://joeyh.name/blog/entry/announcing_debug-me/

I'd considered approaches like this, and I think no matter how you do it this introduces

at least two new issues.

In short, as this is going to be a verbose reply.. this is

more adding to our problems than solving them. We don't need/want this kind of thing

thats more how XP (and onward) Help and Support Center offers that option of remote

support from a friend.. thats certainly something we can toss in there.. a link to use

one of our remote desktop features, but thats not an acceptable form of support for

the Debian project to endorse or encourage from strangers online no matter what

methods are taken. Any "official" support steps should follow the spirit and policies

of the Debian project itself, tested/stable methods, OPEN collaboration, and peer

review.. not some point-to-point connection of a single supporter.

First issue being the obvious security implications which this

method of dealing with requires the existence of and time/willingness of supporters

who are going to use the software.

Second issue being that our support model differs from

and is better than most commercial support models BECAUSE it allows for multiple

supporters to give input and solutions are cross-examined by others experience forming

a consensus opinion and giving the user not only choices, but ultimately making anything

done on their system, being done by them thus removing any liability for anything more

than advice.

The goals of this project however is not to change our support model for anyone other than

the inexperienced user giving them a simpler interface that walks them through our steps

of support. The tools available to supporters on mailing lists, irc, or developers/maintainers

will not need to be embraced by them or require them to change their preferred methods of

support nor will it require them to dedicate time to any one particular issue until it's resolved.

These are volunteers not paid supporters. This system I visioned is op-in and merely extends

and wraps their available toolset in a synergistic way where even if they don't embrace it, they

are still contributing to it. The use of GPG/signing and such here is only required for creation

of diagnostic tree files which will have open peer review and will present steps to the user

prior to them being carried out, so that the user is still in effect running the commands, not

merely doing something like allowing a bot or chat client to run arbitrary commands from random

supporters simply because they signed it.

An example of how these diagnostic trees could work I draw on an issue I had recently where my

sound worked in things like VLC but not in pianobar (pandora) and even with my level of experience

I was utterly baffled by this issue, and come to realize that pianobar used libao which had its own

configuration outside the asound.conf and I had to create a libao.conf and tell it to use asound.conf.

A sound diagnostic tree file would have done things like performed a sound test by using aplay and

asked the user if they heard it, if they said no, it'd check their mixer levels, ask them to check their

connections, and if those things didnt solve it, it would then do something like pulling up aplay -l and

their asound.conf, include this data in a report saying these commands for the sound test and checking

mixer level were run, etc and then let them check existing issues, and move on to IRC/mailinglist support.

However if they did hear the sound of the sound test like I did in this scenario, the core diagnostic

tree would have already pulled up info from apt and know that pianobar uses libao (depends), and

could pull up a diagnostic tree file from package libao provided by its maintainer which shows

location of libao configs and checks those specific things, does a libao sound test, etc. All that

would be very basic stuff and would be signed diagnostics with explanations of each step to be

authorized by the user, and ultimately all this user would be doing if their issue wasn't self-diagnosed

is moving on to our existing support systems with all this data already compiled into a report.

Thus I as an IRC supporter can still be doing whatever I'm doing, and contribute to the issue without

needing to drop my life and setup auth credentials and sign in to some user's computer to poke

around and expect them to trust what I am doing like I'm some all around expert and not merely

a user like them, who has some experience to offer.