[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Project to improve Debian support model

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:


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.

Reply to: