How not to criticise

Posted on February 10, 2010
Tags:
Today I got an e-mail about the GIMP user manual. Those insults are not happening very often, but probably happening for every software project:
Dear Sir,
Open Source software at no financial cost to the consumer is an
incredibly beautiful thing, which I honestly appreciate very much,
however, I have serious concerns regarding the quality of the GIMP user
manual.  Rather than point out the numerous grammatical errors and
flippant writing style I would like to report that the entire manual is
absolutely appalling, possibly the worst computer manual I have ever
encountered, in fact, so bad I report it as being almost evil.

The manual was clearly not written by native English speakers.  The
contents page is too long, sorry, just thinking about that manual is
making me angry and upset so i will leave it at that for now.

If only there is a photo/image editing program that is as well presented
as that on a MacBook. This is the first serious weakness I have found on
OS software, everything else is fantastic!

wishing you a lovely day and I hope that someone is kind enough to
re-write the instructions properly!
[caption id=“” align=“aligncenter” width=“240” caption=“by matthileo on flickr”][/caption]

So what’s the problem with this so called criticism?
  1. The first widespread and common miss-assumption: “Open Source software at no financial cost to the consumer […]”. Free Software is not free as in free beer, it’s free as in free speech. If I like to be picky: GIMP isn’t Open Source, it’s Free Software; there is a difference.
  2. The mail - apart from the rant - doesn’t address any problem. If the author could refer to a specific area in the manual which is faulty (descriptions, paragraphs, a URL of an article) it would allow authors to look for mistakes.
  3. There is no pointer on better ways to do it.
  4. If you know how to make it better, provide patches. We know, that the user manual can be improved in lots of areas. By just ranting against authors you won’t change the manual.

The documentation team knows about the flaws of the manual, but everyone is trying hard each day to make it better. Helpful manuals don’t fall from trees - it’s hard work to produce them. Respect everyone who writes and contributes to free software!