The following is my personal opinion on the general issue of 
non-constructive complaints or opinions.  In no way is it meant to be
offense towards you or any other person who has expressed similar opinions
in the past.  I just feel I have to say it when looking at many similar
messages in this group or received by email...

-----

If we just say that something doesn't work we get comments like "nonsense"
or "explain it"; every time questioning our decisions.  If we try to explain
detailed technical problems in advance we in turn get other people who
second guess our problems and again start _discussing_ the problems and
telling us what we _should_ do and jumping to conclusions without actually
having tried, knowing about or even understanding the problem.

On the one hand very, very few of the people complaining actually go and fix
a problem themselves.  There are many limits in 3.1 that are low priority
for the team, i.e. the 256 entry limit in maps, but we would surely have
added a change if it had been written - the no-source-code-for-3.5 excuse
doesn't cut it in many, many cases.

On the other hand we got a fairly big pile of junk when looking into
individual patches we considered for 3.5 because the patch authors didn't
finish or cleanup their code.  Everybody who has been seriously programming
for some time knows that writing a program that works most of the time is
10% of the work while fixing all the bugs is 90% of the work.  This is what
the POV-Team did for three years now.

If you give us your opinion of our work the way you did, please don't be
surprised if we give you our opinion on your opinion in return.  We always
try to give reasonable explanations and argue as far as it makes sense, but
IMO there is a time when the only response possible seems to be: "Fix it
yourself or shut up!" (this is a quote, I am *not* saying it to you!).  Now,
this would surely be unfriendly and we won't do this as discussion is
something we do want, but we do *not* want constant questioning of our
decisions or abilities.

If you look closely, we get lots of bug reports that are incomplete on three
lines and then all what follows are guesses and wild ideas about the inner
working of POV-Ray on another 25 lines where the person reporting the
problem is trying to do our task of debugging POV-Ray.  This costs valuable
time on both sides.  Us reading what we don't need to know (because 99% of
the time it is wrong and the other 1% we could have found out in 10 seconds
looking at the source code) and the person writing the additional 25 lines
nobody needs.

Yes, a good bug report needs lots of detail, but *only* details *relevant*
to the problem.  These are the steps to reproduce the problem (including
configuration, command-line settings, buttons pressed, etc, etc), the
expected results (what did happen), the actual results (what the user thinks
should have happened) and a workaround (if any - this assumes the user did
take more than five seconds trying different things which help us find the
problem faster).

If you point out a problem with POV-Ray we *do* want to hear about it!  What
we don't want is to hear that we could fix it but don't want to for some
reason because that is simply not true!!!  Or that there is a problem and
arguing over the existence of a problem based on some assumptions about the
inner workings of something the person can't even have seen (because the
source code is not public yet).

Apart from this arguing, if one of our responses is short it sometimes seems
to be taken as disinterest.  Not so!!!  Keep in mind we have been looking at
POV-Ray source code for the past three years, and those who have been
working on a long term project before can surely understand how everyone
will eventually react to something reoccurring after three years.  Even more
so if writing the response in the spare time which is usually late in the
evening or night after a long and busy day.

Our interest is to make POV-Ray as good as possible taking into account that
we don't have a 200 programmer, 100 tech writer and 500 marketing people
company to develop POV-Ray.  We have our spare time and fun to drive us and
POV-Ray forward!

All core POV-Team developers have university degrees in Computer Science or
equivalent qualifications in related fields.  At least Chris Cason and Ron
Parker have considerable decade-long experience developing for Windows and
other systems because they do so for a living.  Nathan Kopp has been working
in the field for nearly two years now.  I am getting a post-Bachelor
university education.  We are not idiots who do not know what to do, we do
*not* need someone else to tell us what is nonsense and what is not!

We may occasionally appear to be less friendly or elaborate when responding
than we should be, so don't take each and every word we say and analyze if
for flaws in our reasoning.  We all do make mistakes, introduce bugs or are
unclear in responses or documentation we write.  All this is human, I think.

-----

This is my opinion, and only my opinion.

Please note that I will (try to) ignore any further discussion responding to
this.

    Thorsten Froehlich

Post a reply to this message