[lug] The changing Linux Community was Re: cp and rm

[D. Stimits]

Tom Tromey wrote:
> 
> >>>>> "D" == D Stimits <stimits at idcomm.com> writes:
> 
> D> Nobody likes being constantly ragged on about something by someone
> D> who wants results for free. But in this case, as annoying as it is,
> D> some of the points by unknowing trolls point out flaws or areas
> D> that need improvement. It sucks when it is done in a way that rubs
> D> badly on the people doing the work, but in the end, not ignoring
> D> the complaints will improve things
> 
> D> Getting people to complain politely would be a better solution than
> D> asking those who know little about the subject to not complain.
> 
> I'm not too concerned about the politeness.  I mean, it certainly
> helps.  Messages that start, "Your program sucks and so do you" aren't
> at the top of my list to respond to.

This is where I tend to differ. I agree that such a response tends to be
"lower priority" for me, and I may totally deny any requests of this
sort, but I'll always read them. I tend to believe that it is important
to know how the ugly perception started. It's part of the Dr. Deming
ideas of tightening tolerances or increasing pressure on the whole
process, in order to find the next weakest link. To me, the uneducated
"Your program sucks and so do you" people are quite possibly wrong about
their conclusions, but it also indicates that something else in the
process is lacking...maybe it is as simple as installation packaging, or
an awkward interface...maybe the interface is actually quite astounding,
but documentation lacked on why it was done the way it was done. My all
time favorite is that some programs are very very capable and reliable
when used correctly, but the steps and procedures to use them correctly
are themselves prone to introducing errors just from complications.
There are cases where the subject is just too complex and there really
isn't a possibility of making the interface less error prone without
educating the user, but studying what causes a bad perception of the
product is very beneficial in the long run.

> 
> My concern is really about the usefulness of complaints.  Sometimes
> people complain in a way that isn't really helpful.  Here's a look at
> the extremes.
> 
> Sometimes I get an automake bug report that says "I tried <something
> explicit> and expected <this> but instead got <that>".  This is great.
> I can understand this and do something with it: from "sorry, this is a
> feature" to "thanks, here's a patch".
> 
> But I also sometimes get reports (usually via some indirect method,
> like, say, the gcc mailing list) that say "Automake sucks" (the short
> form) or "Automake is much too complex.  Why can't it `just work'?"
> (actual complaint).  This sort of thing is really pretty useless.  If
> I'm feeling generous, it might get a response and generate a useful
> conversation.  But by itself it conveys nothing but the poster's
> apparent frustration with some unknown facet of the program.

This is the case where you can't do much about it. On the other hand,
something like this should always stick in the back of the mind when
thinking about new generations of products. Products that are not just
basic improvements of the current product, but instead something that
might be designed in a later generation as a replacement. It won't help
now, and you can't stop those complaints, but it is a really good idea
to know what the user went through in order to determine "....is too
complex. Why can't it 'just work'?". If you know the answer to that, you
can either intervene in the process that the user goes through before
giving up, or be ready for the next generation product. Understanding
the source of frustration is an enormous advantage (but for people with
really bad reporting habits, you'd have to expend effort to know
more...which isn't practical if the work load is already high). I think
of this as the process of frustration becoming a tighter constraint, and
showing a weak link.

> 
> So, there's education for us to do with new users.  We have to explain
> to them why the principles of free software are important (at least,
> those of us who think they are can explain this :-).  We have to try
> to help them understand that free software isn't simply a commodity
> like a fork or a spoon, but instead is deeply intertwined with its
> social structures.  Whether they like it or not, they're in the soup
> with us.  Criticism is really, really useful.  It is much more useful
> than praise!  But it has to be focussed, and specific, and
> unfortunately making this sort of criticism is not a skill we are born
> with.

Yes, I agree completely. So the samples above are basically a tightening
of learning curve prerequisites (critical thought, education,
understanding of free software process). Your statement basically says
that the next logical quality improvement will be achieved most easily
(and at lowest cost) through expansion of the user's awareness of the
whole process. It is the bane of many companies that the next easiest
way to improve product sales is to improve the perceptions of the user.
For governments, this is why they pay for basic educational
infrastructure...it is a long term benefit for everyone. In the case of
non-compulsory education, one has to think in terms of what carrot we
can dangle in front of the horse as motivation.

D. Stimits, stimits at idcomm.com

> 
> Tom
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug