Re: [DotGNU]Professional online tech support for GNU/Linux?

[James Michael DuPont]

Andrew,

After reading your comments, I think that my suggestions go more into
the area after support : bugfixing, and feature implementation. 

You are looking into end user support issues? I am thinking about
developer support issues.

Even at my work most of the users of my software will report bugs,
feature requests, and ask questions, all related to some program or
dialog in the software. All of these things can be traced back to some
module or function in the software. Maybe just to an instance of the
software running on the clients machine.

Of course, If you get a question like "this program is stopping for
some reason, please look into it." That would be a support request that
needs time to debug, you might need someone to log onto the server or
walk you through it step by step. People would pay for that type of
support. Alot of that happens on the #IRC channels.

I was thinking about the types of support questions that I see on the
dotgnu/dia/gcc developers mailling list. Like : "how can I do this?,
implement that?, how does this function work?, what does data
strcucture that do? Oh the program is crashing here, it is slow there,
here is a patch for that. Anyone working on XYZ? How can I get the SVG
output to work?". Those are the types of questions that I find on the
mailing lists and are relevant to the development of a software. 

Development and Bugfixing are functional areas that can be fed by the
support team. If you support team are using the right tools, all
support issues will provide an information gain about you software and
help pinpoint the areas that need improvement.

my comments follow,
mike
--- Andrew Clausen <address@hidden> wrote:
> I disagree fairly strongly with what you said (which is good,
> because we'll improve each others' ideas ;)

Thats ok! As long as we can discuss it.

> I don't think your ideas are compatible with "let's make the system
> really easy for *USERS*".  Users sound like they are priority number
> 5 in your suggestions.  Also, I think it needs to be emphasized that
> support is a service, not a product.  More on these below ;)

Fair point, I am looking at gaining information out of the source code
for the developers. The developers are the "users" of the projects
source code that i am thinking about. The "users" of the executable are
served indirectly by my suggestion. The better understanding a new
developer can get of the program, the better the final product that he
or she can produce will be (i hope).


> On Thu, Jul 11, 2002 at 03:45:32AM -0700, James Michael DuPont wrote:
> > Sounds good.
> > Here are my 2 ? cents : 
That should have been 2 EURO cents, € = Euro symbol, it did not show
up.


> > I want to take this time to point out that the
> > trouble tickets and bugs are the most important meta-data about a
> > software: 
> > 
> > We need to track each issue in a repository and use that to cross
> > reference the source code to the issues, and also the patches to
> the
> > ticket.
> 
> Whoa... most issues won't affect source code at all.  If they do,
> they are no longer support issues, but either "professional services"
> / "consultancy", or bug fixing, which are different animals.
> (With different budgets, time-frames, etc.)
Ok, that is a fair definition. 

Lets say we have support which tracks features request, patches to fix
bugs, bug reports, and just general questions.

For support issues, if an issue is with understanding an input file,
config file, dialog,report, export, it affects source code. Lets say a
user finds a dialog confusing. Cannot figure out how to install/use
because of this, the the issue can be attached to the entire
installation, or to a specific module causing the problem. 

If the have a new feature, or a bug-fix, and optimization, a new output
format, these are all areas where a good development team will be able
to add in information about the request that came from support. 

If the program is just crashing often in one function, or in one area,
this is infomation that a function or area is not stable.

> 
> > >  * how is price determined?
> > Via an ebay bidding system, people put what they will pay, and
> > the developers sell thier time on a market system.
> 
> But, you've got quality issues... also, what information do
> developers have to decide on a fair price?
Sure the quality is an issue. It will be complex to create a contract.
Maybe an hourly charge or a fixed prices. 
A fair price is what the user is willing to pay. 
Lets say we have 100 feature requests, each are described 
by the users to the support staff. This requirement analysis is a taskt
that can be payed for. Maybe $5 for an feature. 

Then the feature is implemented, the time is booked and results
delivered. Now in order to 

>  Should they offer
> a price per unit time?  
That is part of the individual off, you might say, I can do that for
$15 and hour, and I say : I can do that for $20 flat.

> How should a user decide which price/person
> combination is best?
Well, you see the track history of the developer, what people said
about his work and the history of it. You can get/lose points on each
interaction/usecase/resulting work.


> > >  * how do we encourage quality?
> > LIke in ebay or perlmonks, you get downgraded. 
> 
> *downgraded* ?  That sounds like a dubious system, since you could
> presumebly keep opening new accounts.
And you have to start from scratch.
But the accounts have to be secure. 
If you look at debian you have to be Vouched for to be a developer,
advocato lets people vouch for each other.

> In any case, I think users should be able to choose between quality
> and price.
Sure.

> > >  * money is sensitive stuff!  What security is necessary?
> > paypal?
> 
> DotGNU doesn't have anything better to offer?  It seems strange to
> have to go through a third party.


I will leave that up to the others. I dont know enough about its
planned support in DOTGNU. But it is a good question. DotGnu should be
able to help us identify and verify a user and send secure messages to
them. I dont know about payment.....

> 
> > >  * how should it interface with GNU/Linux companies, like Red Hat
> and
> > > friends?
> > it is competition
> 
> Why?  Why shouldn't they be able to participate?
Competition because they provide thier own support that people can pay
for, they might be spending thier dollars somewhere else.

> (note: I developed a lot of this in correspondence with Dan Burcaw,
> who's CTO of Yellow Dog Linux)
And he would not be losing out?
> 
> > >  * what's a simple, easy UI?
> > Something that uses some XMLRPC/SOAP/Jabber/DOTGNU interface into a
> > central webservice. But remember it has to be compatible with
> savannah
> > and should include a client that uses the future to-be-published 
> > php_groupware interface of savannah.
> 
> This question I was asking was more about "what should the user
> see?",
Fine, I was just thinking how a nice dialog system could be bolted onto
an existing system.

> not how it would it implemented (that was another question!)
And what it will look like will be also defined by the technologies
used. If you build it onto sourceforge it will probably look web-like.
If you use a C# GTK client and provide a XMLRPC interface into the
server it might be much more user friendly.

> 
> > >  * which techie "owns" which issue?  How is locking resolved? 
> > I am looking into the debian-sf source code.
> > sourceforge has a nice bug tracking system, and we should look to
> > improve the savannah code to handle this IMHO.
> 
> I'm not convinced that this is related in any way to bug-tracking
> systems.  

> IMHO, bug-tracking systems should be for developers only.
And the users should be able to find if thier bug is there easily,
to be able to see the status of a feature or dialog element. To be able
to click on a bit and report a bug on it. If the user cannot, then the
support staff should be able to. 
Remember for free software, it is also important to make the bugs and
issues visible to the interested developers. If not anything a good
support staff will be producing bits of new documentation in the form
of answers to questions and also capturing new requirements. 

> They require all sorts of interpretation that users probably can't
> do very well, nor have the stomach to do.  They'd much rather fire
> off a 2-minute email to address@hidden, and have a developer
> interpret it for them.
> 
> In fact, I don't envisage support requests being associated with
> programs at all!  More along the lines of: "how can I print this
> pdf file?" or "why won't my epson XFOO+ work?"

ok, and those are driver issues, input and usage issue, all associated
indirectly with functions, dialogs, menus and such. All can be
referenced back to the source code indirectly by naming the dialog
elements. We should be able to extract all the function/module/dialog
names from the source and present them to the users and support staff
for linking them in. This will give a common vocabulary to everyone.
> 
> Basically, I want to bring down the work a user needs to an
> ABSOLUTE MINIMUM.  I don't think users will pay for anything else.

I agree. Mostly I am thinking about the type of support I have seen for
projects like compilers and languages. If you look at www.perlmonks.org
for example you have an excellent support structure there. Many people
do a good job helping others and all they get are points and
recognition.

Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com