[Users] Getting problems solved

[Bert Bril]

Dear users,

To keep OpendTect healthy it's essential we get the right feedback from 
users: remarks, questions, and also problem reports (via 
support at opendtect.org or your plugin vendor's support e-mail). Good 
problem reports will often lead to concrete fixes quickly, and they make 
OpendTect better in general. If a problem is particularly blocking it is 
not uncommon that we make fixes the same day.

Fixing problems requires insight in what exactly goes wrong. 
Reproducibility is (if possible) usually the key to successful problem 
solving. That is why it's so important to be clear about the problem you 
are experiencing, and to deliver the crucial information that we need, 
which can be summarized as follows:
* What version are you working with, on what platform?
* What exactly did you do when the problem appeared?
* What exactly went wrong?
* How can it be reproduced?


To illustrate this, let's take an example. Every once in a while, we get 
the following report:

“Please help! OpendTect doesn't start!”

I sometimes wonder whether the reporter would expect us to immediately 
take a plane and come and help them get OpendTect to start (which we may 
just do if your office is located on the Bahamas). More likely, however, 
we won't do that, so you'll get an answer: “Sorry, but it does seem to 
start everywhere else. Therefore, we think the problem is due to 
something specific in your environment. Can you tell us what happens? Do 
you see anything at all coming up on the screen? What platform is this? 
What version of OpendTect?”. Note that we don't require big bug 
reporting forms to be filled out – that would be counter-productive. 
Just give us something to go on. Thus, a giant leap is the following 
report:
“On my Windows XP OpendTect (2.4.2b) doesn't come up. I do get a 
'console' window at first, I can select plugins, then I see the main 
window coming up but then everything simply disappears. Any ideas?"
Yes, we do have a few ideas now and from this we can start to go into 
more detail if needed.

Another example: a session failing to deliver what it is meant for. A 
report:
“I'm trying to load a session but it fails”
is simply useless. You know what is supposed to come up, so how does 
what you're getting differ from it? Consider this:
“Hi, On Linux (64 bits, v2.5.4) I get wrong results when loading a 
session. When I restore it, the horizons have a single color instead of 
having attributes displayed on them. Moreover, the well displays that 
are in the session never appear – it seems that OpendTect stops loading 
after the horizons. I've attached the session file.”.


It's probably impossible to design a checklist that will work in all 
circumstances. Even if it were possible, it would be unbelievably long 
and hence still unusable. Still, answering the following five questions 
will be a good start:

*What did you work on?*
	[Mac OS X 5 – OpendTect 2.4.1c]

*What were you trying to do?*
	[Tried to calculated an attribute cube using multi-machine processing]

*What did you expect?*
	[When I add a machine, that it appears in the 'used host' list]

*What happened?*
	[Some machines do, some don't appear. When they don't I see a message 
in the console window: 'process_attrib: command not found'.]

*Did you notice anything?*
	[The machines that don't work are all Linux (64 bits) machines.]



Bert Bril

-- 
-- Bert Bril / OpendTect developer at dGB
-- Nijverheidstraat 11-2, 7511 JM Enschede, The Netherlands
-- mailto:Bert.Bril at opendtect.org , http://opendtect.org
-- Tel: +31 534315155 , Fax: +31 534315104