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

[James Michael DuPont]

Andrew, 
I have reread your proposal and understand your points much better now,
sorry to just throw my ideas at you without listening first :)

You have a good idea there, and it could be used to handle all types of
interactions, not just support... Maybe a developer could publish a set
of features that he is thinking about implementing and get votes
back... Not just money but some form of "karma" could be used as
well..... But that is a another issue isn't it!

> > 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. 
> 
> I'm not sure about payment here.  Like, people asking those kinds of
> questions often make significant contributions themselves.  Like,
> it's part of the life-cycle of free software projects.  Perhaps if
> the said person wants the maintainer/whoever to spend more time...
> then money might enter the equation.

Sure and using a money system you can bid for features, and draw your
attention to what needs to be done. But your right, who wants to pay
for features? Hmmm.......

> BTW: are you going to comment on my suggestions in my article?
> (How I think accounts should be set up, etc.)
I just reread your article
http://members.optushome.com.au/clausen/ideas/online-tech-support.txt
I aggree with your ideas there, 
it reminds me of a GREAT trading game M.U.L.E on the atari!

The buyers and sellers can raise and lower the price/offer and they
meet in the middle.

> > 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).
> 
> Can you give me an example?  Like, I'm skeptical that this would
> make much sense in practice.  The said "users" are probably in the
> "more-time-than-money" category?  Or at least, they're just doing
> their job.

Like you search the cvs logs, documentation, the bugs reports and the
mailling list for finding out what was said about a given function or
data structure that you are working on. The indexing of this
information could be greatly advanced by some tools.
I am thinking about the type of information provided by doxygen or
javadoc, but handling also files and user interface elements. 
Basically you need to provide a vocabulary to the users to talk in a
structured manner about your application, an ontology.

> > > 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.
> 
> I guess this could possibly be useful, but it sounds like a lot of
> work.  I think the supporter liasing with the developers should
> be sufficient.  But, once a system is up-and-running, I guess it
> could be useful.  I reckon it's best to wait and see ;)  (Let it
> grow!)
Yes I agree, but look at the loss to the GNU project that all the mails
about the gcc are not public. Much information and documentation about
the gcc is not public, only via the egcs takeover was it possible to
get the mailling list publicized. 

It would be of great importance to have logs of the transactions made
available for later useage. Also to allow for the developer to present
a categorization system that can be used by the users.

> > 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. 
> 
> I reckon I have a better solution!  See my webpage.  (You missed it?)
yes you do! sorry.

> I think this is too vulnerable to attack.  I think certification
> should
> be done by certifiers and developers, because they have a public
> face,
> and can't ditch their identities easily.  Basically, I think advogato
> is the Right Way TM.

Yes I aggree that avogato is good. 
 Just that the individul interactions get a rating as well. 

> > > 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.
> 
> Please see my comments on my webpage about this.
Yes, it would be fine as a simple dialog. But it would also make sense
to provide an interface into the sourceforge/savannah system for
tracking it.....

> > > 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.
> 
> It'd be nice to have at least a web interface... more portable.
At least I aggree. But the web interface should not be the end-all-be
all. 

> 
> > > 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. 
> 
> Sure, users should have access to this info.  But I don't think they
> should be obliged to go through this.
Fine, it is a value added service. We should however provide some way
of caputuring the transactions relating to a bug.

> > 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.
> 
> Can you describe a scenario ("user clicks here and sees X!  Developer
> receives Y and is enlightened!") where this helps?  I don't really
> understand your point.

If your software has a dialog element, you can provide a way to select
a menu anywhere in the program to report a bug about the current
screen... 

like a talkback system, except that you dont have to crash the thing,
and you can automatically infer the current state of the software by
some standard means.... Even the callstack would be fine for most
applications....

Otherwise the software developer needs to provide a list of catagories
about his software that can be used to report bugs about. That could be
a standardized format so that all parties can suggest new
classifications.....

Regards,
mike

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

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