On Sat, Oct 21, 2017 at 9:40 PM, Paul Wise <[email protected]> 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.
