On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote:

Hi

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

What about downloading it and checking yourself?

ciao, --mitch

Federico Alcantara writes:
> I am interested in knowning if Gimp is written in C/C++,

There is no programming language called C/C++.

GIMP is written in C. It can be scripted in Scheme (a dialect of Lisp), and the usual suspects Perl and Python.

> and which tools are needed to compile, debug, and test it?

A compiler, a debugger, and a human tester.

Which compiler and debugger depends on the platform. On Linux and most other Unix systems, that would be the GNU ones, gcc and gdb. Proprietary compilers like Sun's compiler on Solaris can be used, too. On Windows either gcc or Microsoft's compiler can be used.

--tml

From: Federico Alcantara

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

You can find a brief overview at

http://wiki.gimp.org/gimp/SummerOfCode

and a lot more detailed information at

http://developer.gimp.org

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Wed, 2007-03-14 at 20:52 +0100, Michael Natterer wrote:

On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote:

Hi

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

What about downloading it and checking yourself?

IMHO, refraining from posts like this could greatly improve the atmosphere of this list.
It is really up to you to help somebody with answering his question or not to help, but this "answer" only hurts and helps nothing.

ciao, Alpar

ciao,
--mitch

Alpár Jüttner (alpar@cs.elte.hu) wrote:

On Wed, 2007-03-14 at 20:52 +0100, Michael Natterer wrote:

On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote:

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

What about downloading it and checking yourself?

IMHO, refraining from posts like this could greatly improve the atmosphere of this list.
It is really up to you to help somebody with answering his question or not to help, but this "answer" only hurts and helps nothing.

I don't agree with you there. The information Federico asked for is provided in the readmes accompanying the GIMPs source distribution and on the websites. We put that stuff there, so that people are able to locate it in the tarball and/or in search engines.

This mailinglist is not a forum to save everybody the most basic research. If we are supposed to answer these questions, is it sufficient to answer the questions once? Three times? Every time?

It would drastically reduce the signal-to-noise ratio of this list and make it less useful, since I'd have to dig through a lot of trivial questions to spot the interesting discussions.

Feel free to jump on mails that were impolite and/or rude, I know that these sometimes happen. But this specific mail from mitch was not one of them.

Bye,
Simon

Alpár Jüttner wrote:

On Wed, 2007-03-14 at 20:52 +0100, Michael Natterer wrote:

On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote:

Hi

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

What about downloading it and checking yourself?

IMHO, refraining from posts like this could greatly improve the atmosphere of this list.

Looks like a reasonable answer to me, given the nature of the question.

On Monday 19 March 2007 08:11, Simon Budig wrote:

IMHO, refraining from posts like this could greatly improve the atmosphere of this list.
It is really up to you to help  somebody with answering his question or not to help, but this "answer" only hurts and helps nothing.

I don't agree with you there.
... (remaining ranst tossed on bascket)

Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL???

You see, the GIMP is not exactly with exceeding developer resources, and every single person I see trying to approach the project either here or over bugzilla gets a rude answer that might have turned then away for good. Examples from the last 48 hours include a "help yourself" (bug #329020 - 2007-03-20), "we don't take bug reports against outdated development versions anyway." (bug #420170, 2007-03-19)

The guys organizing LGM had called my attention to the point that GIMP is a project perved as hostile towards newcomers.

I even addressed in private some hostile postings on this list over the last weeks to try to start changing this general behavior - but it looks it is just too overspread.

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so.

You can think ut whatver you want, mutter whatver you want, write a scratch however you want - I ma just askign that before hitting the "post" button you go back to thetext and add some of the magic words - even if in your heart you are lying.

Example: from:
"we don't take bug reports against outdated development versions anyway."
to:
"Please, post bugs only using the latest development version. "

(that if one is really unwillingly to type a few more characters)

sincerely, js
->

Hi,

On Mon, 2007-03-19 at 23:35 -0300, Joao S. O. Bueno Calligaris wrote:

Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL???

Feel free to add those, no one forbids it. But seriously, the question was stupid and the answer was short but helpful. We could as well have ignored the question because it was unappropriate for a developer list where some basic research before posting can be expected. Don't forget that this list is a place for GIMP developers, not a help forum.

Joao, I am seriously offended by some of the things you said in your mail. But I will assume that this is a misinterpretation just like you are obviously misinterpreting the intents of some people here.

Sven

Von: "Joao S. O. Bueno Calligaris"

You see, the GIMP is not exactly with exceeding developer resources, and every single person I see trying to approach the project either here or over bugzilla gets a rude answer that might have turned then away for good.

There are canned messages in Bugzilla. In my opinion, they are a bit too friendly - I know for sure that I'd get annoyed by ten "Thanks" for bugs that are closed as duplicates.

Their main problem, is that besides a firendly "Thanks" and some explanatory text about why the bug is in its current state now, there's no further helpful information, like "this bug is a duplicate[...] you can check for existing bugs at http://bugzilla.gnome.org/browse.cgi?...".

I've talked to one of the Bugzilla maintainers about this, but so far nothing has happened (he didn't make any prmises, to be fair). Maybe this should be proposed again.

Example:
from:
"we don't take bug reports against outdated development versions anyway."
to:
"Please, post bugs only using the latest development version. "

We do have a list etiquette at http://www.gimp.org/mail_lists.html. I'd like to suggest that it is moved above the mailing lists, maybe it will be read more often then.

We even have a paragraph there about the situation above:

"Check your facts. Before reporting problems, check again. Make sure you are following the intructions correctly and that your version is not old[...]"

Maybe we should advertise it a bit more - standard gimp.org message footers, anyone?

In addition, I think that the list etiquette should point to the "smart questions" guide: http://www.catb.org/~esr/faqs/smart-questions.html

Yes, I know that some think that this document is rude, but it has been incredibly useful for me. I always go back and read it when I find myself asking too many simple questions per time frame.

HTH, Michael

Joao S. O. Bueno Calligaris (gwidion@mpc.com.br) wrote:

On Monday 19 March 2007 08:11, Simon Budig wrote:

IMHO, refraining from posts like this could greatly improve the atmosphere of this list.
It is really up to you to help  somebody with answering his question or not to help, but this "answer" only hurts and helps nothing.

I don't agree with you there.
... (remaining ranst tossed on bascket)

Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL???

Nothing forbids that. The absence of these things does not make an answer rude though, which is the point I am arguing. I did hope that I made that clear in the rest of the message, but since you perceived that as a rant I seem to have chosen the wrong words.

As I said: there are other messages that can be interpreted as very abrupt or curt, no doubt about this. And I really think that it makes sense to reconsider certain "standard" sentences, especially - as Sven explained - there certainly is no hurt intended.

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it?

Since you were referring to me specifically as well, I'd like to ask you to point out to me when/where I have chosen poor words or disrespect towards the other human being. Feel free to discuss this on the list although private mail probably is more appropriate.

Bye, Simon

On Mon, 2007-03-19 at 23:35 -0300, Joao S. O. Bueno Calligaris wrote:

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so.

Come on, that is simply a rude accusation. Definitely more rude than giving a small "check for yourself" to a question that clearly shows that the person did not do the slightest bit of work by itself.

I don't see the point in answering questions that are *trivial* for *everybody* to answer themselves, regardless of abilities or experience.

Yet each time such questions come up, somebody steps forward and answers them. That is simply no help at all for the person who asked the question. A "you can find out yourself trivially" is infinitely more helpful than doing the people's work for them.

whatever...

--mitch

On Tue, 20 Mar 2007 11:28:49 +0100, Simon Budig wrote:

Joao S. O. Bueno Calligaris (gwidion@mpc.com.br) wrote:

Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL???

Nothing forbids that. The absence of these things does not make an answer rude though, which is the point I am arguing.

The absence of thanks may be perceived as rude, especially in the context of a bug report closed as WONTFIX, INVALID or NOTGNOME...

Let's take the perspective of the bug reporter: if you report a bug or suggest an improvement and your report is rejected by the developers, then your initial impression will be slightly negative. A "neutral" explanation may be perceived as rude because you took the trouble to find out how to report GIMP bugs, you registered in Bugzilla, you spent the time to write the bug report and the only thing you get in return is a too brief message telling you that your bug report was rejected.

Contrary to what Michael wrote in another message, I like the canned replies in Bugzilla because most of them start by thanking the reporter. Although I agree that they could be improved and could include two lines about how to avoid duplicates in the future or how to find some FAQs and so on, they are good enough in most cases. These thanks help to offset the negative impression that the reporters might have after seeing their bug reports rejected or marked as a duplicates of another one.

In summary, never assume that a short message is "neutral". The context may lead to a negative perception of your message so it is useful to compensate for that by being more polite than usual. And yes, this may mean thanking the 100th clueless user who suggests again to support more than 8 bits per channel or to improve the user interface by implementing some kind of MDI model.

-Raphaël

There is a practice within OO bugzilla management (at least with some QA persons) to 1. thank the bug reporter for his work - whether it is useless from a developer's POV or not. 2. if it is a well-known bug or the problem should be known from FAQ or other online document, the link to this document or to the original bug is presented. As I use OO from its first public builds, I can say such an approach is much appreciated and inspires a reporter to proceed with the investigations or with the program itself. I definitely do not want to offend anybody on this list as often I am in a developer's shoes myself.

Raphaël Quinet wrote:

Let's take the perspective of the bug reporter: if you report a bug or suggest an improvement and your report is rejected by the developers, then your initial impression will be slightly negative. A "neutral" explanation may be perceived as rude because you took the trouble to find out how to report GIMP bugs, you registered in Bugzilla, you spent the time to write the bug report and the only thing you get in return is a too brief message telling you that your bug report was rejected.

Contrary to what Michael wrote in another message, I like the canned replies in Bugzilla because most of them start by thanking the reporter. Although I agree that they could be improved and could include two lines about how to avoid duplicates in the future or how to find some FAQs and so on, they are good enough in most cases. These thanks help to offset the negative impression that the reporters might have after seeing their bug reports rejected or marked as a duplicates of another one.

On Tue, 20 Mar 2007 12:21:23 +0100, Michael Natterer wrote:

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply remember the person on the other side is still a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so.

Come on, that is simply a rude accusation.

Is it rude? It seems perfectly reasonable and polite to me. Interestingly Sven seems to find this highly offensive as well. May be you think taking offense somehow negates the criticism. It seems you both are not too good a taking what you give out to others and quick to take offence where it was not even intended.

Simon , who I cant remember as being rude or off-hand to anyone, seems confused yet polite, not offended.

The post that sparked this thread seemed fair to me, it was a lazy question that got a helpful but deservedly terse reply, but there have been many examples of ppl being badly received and I've already commented on that myself. It's one reason why the number of contributors to gimp is limited. It does nothing to further gimp.

I agree with Alexander's comments. I have submitted bugs to a number of projects that I use and have nearly always been well received. I can only agree that getting a polite response , even if the report is mistaken in some way, builds good will. I come away with a positive impression and I get more enjoyment from the software. I'm more inclined to recommend it to others.

gg

gg@catking.net writes:

Come on, that is simply a rude accusation.

Is it rude? It seems perfectly reasonable and polite to me. Interestingly Sven seems to find this highly offensive as well. May be you think taking offense somehow negates the criticism. It seems you both are not too good a taking what you give out to others and quick to take offence where it was not even intended.

One key aspect is Joao's comment that outsiders preceive the project as rude -- and he gave several very recent examples of why this perception exists.

Even if an original question seems rude or stupid, answering it in a rude or brusque manner creates a perception that GIMP is not a friendly project for outsiders.

Maybe that's the intent -- to set up a gauntlet that weeds out any potential participants who might be lazy or thin skinned. If so, no problem. But if you actually want lots of new participants, then how other people perceive the project matters.

Being perceived as friendly takes some effort -- and sometimes it means trying to seem friendly even when you don't feel that way, and even when you feel justified in being abrupt because the question was lazy.

Simon , who I cant remember as being rude or off-hand to anyone, seems confused yet polite, not offended.

Yes, it's ironic to see Simon targeted in this discussion -- he is not one of the main offenders here and is consistently friendly and helpful in general.

Joao S. O. Bueno Calligaris writes:

Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL???

Is there a FAQ URL? There's nothing linked from the top level of gimp.org. There is a FAQ page on the wiki, but it begins with a disclaimer that it's out of date and people should go to the GIMP manual instead (which doesn't answer most of the FAQ questions). I wish the person who added that out-of-date notice had actually mentioned *which* answers were out of date, which would make it a lot easier for volunteers to find and update them.

And the FAQ doesn't have anything on the language(s) used to write GIMP. I know it sounds like a stupid question -- that was my reaction too -- but it's not the first time I've seen it asked on the mailing lists, so maybe it belongs in the FAQ after all, along with how to take a quick look at GIMP code (viewcvs) without downloading the whole tarball.

Except I'm hesitant to run off and register for the wiki so that I can add it, given that it's not linked from the main GIMP site, no one refers to it and the page itself discourages anyone from using it.

If there's no easy-to-find FAQ document, then is it fair to get mad at people for asking FAQs?

On 3/20/07, Akkana Peck wrote:

If there's no easy-to-find FAQ document, then is it fair to get mad at people for asking FAQs?

Currently gimp.org is in process of redesigning. I think that adding another todo with regards to FAQ would be one step closer to being percieved as nice people by mere mortals.... err users :)

But this is a topic for gimp-web@ rather than gimp-devel@.

Alexandre

(oops, sent privately: resending to list)

On Mon, 19 Mar 2007 23:35:30 -0300, "Joao S. O. Bueno Calligaris" said:

You see, the GIMP is not exactly with exceeding developer resources, and every single person I see trying to approach the project either here or over bugzilla gets a rude answer that might have turned then away for good. Examples from the last 48 hours include a "help yourself" (bug #329020 - 2007-03-20), "we don't take bug reports against outdated development versions anyway." (bug #420170, 2007-03-19)

To be honest, as a lurker, I find the whole "let's endlessly debate how to be polite to users" a huge putoff, and indicative of problems within the GIMP developer community. Much more so than a terse response, or even a slightly rude "You have a brain, now use it. Here's a hint" style of response.

Let's just end this with "Try to be more polite, and provide pointers on the correct thing to do instead of just saying no."

This whole debate is a waste of time, effort, and I'm probably not helping by posting this.

Please, everyone, just stop acting childish, this isn't worth debating.

/me gets back to lurking.

Hi Mitch and everybody!

On Tuesday 20 March 2007, Michael Natterer wrote:

On Mon, 2007-03-19 at 23:35 -0300, Joao S. O. Bueno Calligaris wrote:

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so.

Come on, that is simply a rude accusation. Definitely more rude than giving a small "check for yourself" to a question that clearly shows that the person did not do the slightest bit of work by itself.

I don't see the point in answering questions that are *trivial* for *everybody* to answer themselves, regardless of abilities or experience.

Yet each time such questions come up, somebody steps forward and answers them. That is simply no help at all for the person who asked the question. A "you can find out yourself trivially" is infinitely more helpful than doing the people's work for them.

Actually I also think it was too rude. Let's analyze it:

<<<<<<<<<< On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote:

Hi

I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it?

What about downloading it and checking yourself?

ciao, --mitch

1. You didn't say "hi".

2. You phrased it as a question that implied the original poster should have thought abuot it himself, instead of giving an answer.

If I were you I would have written the following:

<<<<<<<<<<

Hi Federico!

The core GIMP code is mostly written in ANSI C. You can learn about its source code and how to compile it by checking out the source according to the instructions in the following URL, and then looking at the HACKING, INSTALL and README files:

http://www.gimp.org/source/

Regards,

Shlomi Fish

It took me 10 minutes to write.

However, I believe Alpár's and Joao commentary was induced by the general trend of treating people on this list (and potential future contributors) rudely or impatiently. I've noticed this general trend here too after someone made me more aware of it.

I believe the GIMP could have been much better off today, if it weren't for all the antagonism that the developers' have created. I mean, sure after Spencer Kimball and Peter Mattis left the project and most of the other original developers left to work on GNOME, very few developers were left. But since then the community of FOSS developers grew by leaps and bounds, and there shouldn't have been any problem finding much more potential developers than we have today. There are plenty of fish in the sea.

Let's look at Inkscape for a counter example. They have been around for a much shorter time than the GIMP, but have made remarkable progress, because the atomosphere they have is much better. If they could do it, why can't we? Only because we reject potential developers.

Another good example for a well-run project is Subversion. I've been personally involved in developing it, and it is run in an excellent manner. It already has 126 commiters (exlcuding some contributors without a commit bit), and is very sophisticated, solid and successful. It is probably the most popular open-source alternative to CVS, and is used by many projects including by GIMP and the rest of GNOME. Again none of this would have been possible without the core developers working hard on creating a good atomosophere.

And Karl Fogel, a core Subversion developer have written a book about exactly that:

http://producingoss.com/

(Freely available online)

It would probably make a good read.

Also of interest is this interview I conducted with Ben Collins-Sussman (another Subversion developer) where we touched upon the topic:

http://www.shlomifish.org/open-source/interviews/sussman.html

Now, a few possible ways I can see to handle the situation:

1. Create a page with some FAQs and canned responses in both HTML and plain text formats. I volunteer to prepare and maintain this page. I also get sick of reading more "You should change the name of the GIMP, it is an insult in English", "When is CMYK/16-bit/whatever support coming?", etc. questions, but I believe we can at least answer them politely.

2. Have a system of self-moderation. Let the messages of developers with a tendency to be rude and untactful pass through a small forward of "friendliness experts" for approval and correction. IF the experts are unhappy, they'll tell the senders to edit them and re-send them.

Note that I'm not necessarily suggesting we force it down the developers' throat, although it may not be a bad idea either.

3. One good trend that I noticed is that Carol Spears has stopped posting messages on the mail lists. Hopefully this trend will continue into the future, because she's been doing a lot of damage previously.

4. Otherwise have the developers pay attention and try to be as hopsitable, friendly and tactful as possible. Reading the Producing OSS book would be a good start.

-----------------

If we make GIMP better in this regard, we can have much more contributors, a better perception among the community, and this will lead to a faster development rate.

So let's do it and rock this joint!

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.

gg@catking.net (gg@catking.net) wrote:

On Tue, 20 Mar 2007 12:21:23 +0100, Michael Natterer wrote:

It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply remember the person on the other side is still a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so.

Come on, that is simply a rude accusation.

Is it rude? It seems perfectly reasonable and polite to me.

Actually I too think that this is - uhm - not very carefully worded. It implies that we actually do judge people only by their coding abilities and/or cluelessness. Which is something I personally do not like to hear about me (because I don't think it is true).

To be a bit more constructive here: If our way of communicating gives the *impression* that we judge people by their coding skills only, then we should try to work on this. I think that (especially in the bug reports) there are subtle things that already would improve a lot:

- replace "obviously" with "apparently". - replace "useless" with "not helpful" - sprinkle more "please" and "thanks"

there are probably other simple examples that would kind of defuse the perceived rudeness. To me it is important though that we avoid the "corporate speak" sound of some other projects, which in itselfs also creates a barriere between the users and the developers as well.

As for the missing "canned responses" - it probably is fairly easy to whip up a small javascript bookmarklet, that fills in the comment section of a bugzilla entry, if one is really ambitious one could write an firefox extension that automatically adds these to the context menu. But really - a text file on disk with all of these would suffice.

Bye, Simon

Hi.

Shlomi Fish (shlomif@iglu.org.il) wrote:

It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 "lazy questions" per hour a waste of time.

(Sorry for not replying to all of your mail - this just stuck out to me)

Bye, Simon

yep, Gimp's team has its own reputation : not very opened to outside things. may be this is not completely true, for examplegimp's team has been opened to join LGM instead of going on with the GimpCons.

I guess nobody is responsible and everyone can be. The fact can Gimp is a quite huge and complex software, and now existing for a long time, is the first explanation for not seeing new contributors. Everyone trust gimp's team quality ;)

But it is true that Gimp has many user. The trouble is how to have feedback from users (this is one of the FOSS basis), and in the same be able to evaluate the quality of the feedback without judging.

As a graphic designer, and with all the efforts i like to do, i cannot reach the level is needed to expose seriously the bug i get. I learned thisyear how to do a gdb, and i'm following Gimp/Scribus/Inkscape each for years now. And i succeed to do this backtrace only because Bryce and ACSpike took two night to explain me. And even when we report, it is hard to see if our bug is an existing or a new, just because we are never completely sure it is a bug!
Just have in mind that any other user will be less involved than i am, and that, for them, doing a report is a very impressive task. Even if it is bad reported.

it is sure that the more gimp is used, the more the gimp will receive junk reports. But is it a good option to say (as i heard recently) that gimp's team never wishes to have more users. Now that Krita is existing and people taking interest in it, may be the Gimp it self could be in danger and IMO that could be a big loss for FOSS.

I don't have any advise to give to contributors, and noone to blame. I know that i've sometimes been hurt by some rude behavior (or what i interpreted as so). I'm convinced so this doesn't really hurt me, and i don't forget that i'm using only FOSS that are mostly coded by volunteer, and i'm sure i don't thank them enough for that. But i guess other people will react another and just turn the head.

pygmee

On Tuesday 20 March 2007, Simon Budig wrote:

Hi.

Shlomi Fish (shlomif@iglu.org.il) wrote:

It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 "lazy questions" per hour a waste of time.

Well, a few notes:

1. I didn't measure how much time it took me exactly. It was probably less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

2. I had to find a URL which more experienced developers would know by heart.

3. 10 minutes is much less time consuming that writing a bug-fix or an enhancement patch for the GIMP or for any other program. If it takes me 10 minutes to answer someone in a polite, friendly and encouraging way and he or she later become an active developer, then I may have "wasted" 10 minutes, but subsequently got hours and days of voluntary development in return.

Which alternative is better? You decide.

(I'm not saying any people who is friendly will become so, but the fact is we've deterred a great deal of potential contributors due to such behaviour.)

4. I believe it can be further reduced by creating an FAQ or a pharsebook of canned responses.

5. If you don't want to answer it - just skip to the next message, and let someone else answer it.

6. I believe many questions can be eliminated into the future by good human factors engineering. See for example:

http://www.joelonsoftware.com/articles/customerservice.html

Reading from it:

<<<<<<<<< Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem. But when you think a little harder you can usually find a deeper solution: a way to prevent this particular problem from ever happening again.

Sometimes that means adding more intelligence to the software or the SETUP program; by now, our SETUP program is loaded with special case checks. Sometimes you just need to improve the wording of an error message. Sometimes the best you can come up with is a knowledge base article.

We treat each tech support call like the NTSB treats airliner crashes. Every time a plane crashes, they send out investigators, figure out what happened, and then figure out a new policy to prevent that particular problem from ever happening again. It’s worked so well for aviation safety that the very, very rare airliner crashes we still get in the US are always very unusual, one-off situations.

Speaking for experience, I got many emails for Freecell Solver ( http://fc-solve.berlios.de ), in which I was asked something along the lines of "I unpacked the zip file, double clicked the executable but all I get is an empty DOS BOX"). This happened because the executable just expected to receive standard input, and people who downloaded the Windows binary expected it would start a GUI. As a result, I added a small blurb to the standard error saying:

<<<<<<<<<<<<
Reading the board from the standard input. Type "fc-solve --help" for more usage information. To cancel this message set the FREECELL_SOLVER_QUIET environment variable.

And as a result, I no longer received such messages, and was no longer bothered by them.[1]

If someone asks a question times and again, then we can probably restructure the web-site, the program, the online help or whatever to prevent them from re-occuring.

(Sorry for not replying to all of your mail - this just stuck out to me)

No problem. Although I would like to receive a reply from you or someone else.

Regards,

Shlomi Fish

[1] - It is possible that after reading this message, the people who downloaded and run the Windows binary just gave up on the program. But at least I was no longer bothered with it.

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.

Shlomi Fish (shlomif@iglu.org.il) wrote:

On Tuesday 20 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 "lazy questions" per hour a waste of time.

Well, a few notes:

1. I didn't measure how much time it took me exactly. It was probably less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

Ok, granted. I was just surprised that you'd seem to take this as something not noteworthy.

2. I had to find a URL which more experienced developers would know by heart.

That is a misconception. I personally do know exactly one URL of the website by heart: "http://www.gimp.org/", ok, two: "http://www.gimp.org/tutorials/". Everything else is opening it in the browser and search for the appropriate link (which in this case is prominently in the menu structure). I do believe that this is the same for all developers not actively working with the site itself.

3. 10 minutes is much less time consuming that writing a bug-fix or an enhancement patch for the GIMP or for any other program. If it takes me 10 minutes to answer someone in a polite, friendly and encouraging way and he or she later become an active developer, then I may have "wasted" 10 minutes, but subsequently got hours and days of voluntary development in return.

Which alternative is better? You decide.

Well, if it were fun to answer these kind of obvious questions that two minutes researching on the gimp homepage would have solved then you'd have a real point. It is not fun though. To the contrary.

And frankly, we put a lot of effort into the source package to make it as easy to compile as possible. I firmly believe that the quality of GIMPs code is a lot better than that of a lot of other free software projects, mostly because especially Mitch and Sven have very strict guidelines for patches.

Then somebody comes and asks if Gimp is written in C/C++? I mean, come on. That is like asking "I want to become a computer scientist. How does a computer work?". It is just a painful question.

(I'm not saying any people who is friendly will become so, but the fact is we've deterred a great deal of potential contributors due to such behaviour.)

There are some easy things we can do to improve the communication with other people, no doubt about this.

[further good points snipped]

Bye, Simon

Shlomi Fish (shlomif@iglu.org.il) wrote:

Actually I also think it was too rude. Let's analyze it:

[...]

1. You didn't say "hi".

Oh, come on. A lot of the mails on mailinglists don't include a greeting if quoting something. I've never perceived that as *rude*.

2. You phrased it as a question that implied the original poster should have thought abuot it himself, instead of giving an answer.

Oh, come on again. It is not unusual to formulate a suggestion in terms of a question. To pose this as rude is IMHO blown way out of proportion.

I really don't get why this discussion sparked from this specific mail. Please also keep in mind that most of us are *not* native speakers and discussing stuff in this linguistic nuances is probably a wasted effort.

[...]

However, I believe Alpár's and Joao commentary was induced by the general trend of treating people on this list (and potential future contributors) rudely or impatiently. I've noticed this general trend here too after someone made me more aware of it.

Funny, my impression is, that it got better in the last few months.

I believe the GIMP could have been much better off today, if it weren't for all the antagonism that the developers' have created. I mean, sure after Spencer Kimball and Peter Mattis left the project and most of the other original developers left to work on GNOME, very few developers were left. But since then the community of FOSS developers grew by leaps and bounds, and there shouldn't have been any problem finding much more potential developers than we have today. There are plenty of fish in the sea.

I am concerned that this might not be exactly true. I don't have specific numbers, but my impression is, that it is way harder to sort the wheat from the chaff nowadays. In the beginning of the GIMP the people who a) found the GIMP, b) bothered to subscribe to the mailinglist, c) expressed interest in contributing generally already were enthusiasts about free software. They used stuff like e.g. slackware to convince their boxes to boot into linux. They were editing textfiles to get an internet connection. They had a thorough understanding of their system. This is no longer the case today. I mean, I am teaching stuff at the CS department of our universities and there really are students here who never did any programming and/or are annoyed if they have to. I mean, WTF?

Granted, the pool became bigger, but the amount of fish in it did not increase in the same proportion. And there are a lot more projects fishing around in there.

I am not sure if this is a fair description, I probably sound a little bit like a grumpy old man. Not sure what to do about this though... :)

Let's look at Inkscape for a counter example. They have been around for a much shorter time than the GIMP, but have made remarkable progress, because the atomosphere they have is much better. If they could do it, why can't we? Only because we reject potential developers.

I believe that "reject" is the wrong word here, because it implies that we'd do this on purpose which is in general not true. We do have a habit of expecting a lot from patches (look at the number of iterations some patches go in bugzilla) but in general I believe that even the original patch author will agree that the result is way better than what was originally submitted. We also have the habit of expecting more than half-baked ideas when someone comes up with an idea and sometimes ideas are probed a lot before a developer admits that it might be a good idea.

I guess that these intentions do not always make it through to the person presenting the idea and they take it as a hostile attitude of the gimp developers (sometimes even "threatening" us with switching to other applications). This is the area where we probably can improve things a lot by being more careful with the language. However, the probing in itself is necessary and important for the quality of the Gimp.

[and regarding inkscape - I like the project a lot and I don't mean them any harm, but they lost me as a contributor even before I tried to communicate with them - 430 source files in a single directory is a good way to do this, hopefully they will improve there.]

About your suggestions:

1. Create a page with some FAQs and canned responses in both HTML and plain text formats. I volunteer to prepare and maintain this page. I also get sick of reading more "You should change the name of the GIMP, it is an insult in English", "When is CMYK/16-bit/whatever support coming?", etc. questions, but I believe we can at least answer them politely.

Please add "I will switch to [whatever]" to that list...

2. Have a system of self-moderation. Let the messages of developers with a tendency to be rude and untactful pass through a small forward of "friendliness experts" for approval and correction. IF the experts are unhappy, they'll tell the senders to edit them and re-send them.

Note that I'm not necessarily suggesting we force it down the developers' throat, although it may not be a bad idea either.

I think it is a bad idea. We do have to be careful that Gimp stays fun for ourselves. Putting ourselves in a self-surveillance-corset is a great way to kill the fun IMHO.

3.

[snipped - that was IMO not necessary]

4. Otherwise have the developers pay attention and try to be as hopsitable, friendly and tactful as possible. Reading the Producing OSS book would be a good start.

I might give it a shot.

Bye, Simon

Hi Simon!

Let me just say that I found your response (and your response to my other email) well-thought and constructive, and generally agreeable. However, now I have some higher priorities (not GIMP related unfortunately) so I will reply[1] to this email later when I have some spare cycles.

But thanks for a great response.

Regards,

Shlomi Fish

[1] "Will reply" is subject to the Rule of Open-Source Programming[2] No. 11, which says that when a developer says he will work on something, then he or she means "maybe".

[2] - http://www.shlomifish.org/humour/fortunes/osp_rules - and yes, most of them are my own invention. Read at your own risk and take with a grain of salt.

On Wednesday 21 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

On Tuesday 20 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 "lazy questions" per hour a waste of time.

Well, a few notes:

1. I didn't measure how much time it took me exactly. It was probably less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

Ok, granted. I was just surprised that you'd seem to take this as something not noteworthy.

2. I had to find a URL which more experienced developers would know by heart.

That is a misconception. I personally do know exactly one URL of the website by heart: "http://www.gimp.org/", ok, two: "http://www.gimp.org/tutorials/". Everything else is opening it in the browser and search for the appropriate link (which in this case is prominently in the menu structure). I do believe that this is the same for all developers not actively working with the site itself.

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.

On Wednesday 21 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

On Tuesday 20 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 "lazy questions" per hour a waste of time.

Well, a few notes:

1. I didn't measure how much time it took me exactly. It was probably less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

Ok, granted. I was just surprised that you'd seem to take this as something not noteworthy.

Well, I don't believe spending 10 minutes writing an email is a waste. I spend more time on most serious emails. When I write emails I invest a lot of conscious effort writing them. Most of the time I read the email to which I respond to the end before hitting the reply button. And most of my important emails are properly-cased, and with as few spelling/grammatical/syntactical/etc. problems as I possibly can, with me even trying to use the best possible phrasing. All of which subject to the fact that English is my second language, and that I have audible perception, which makes several ("It sounded so much better in my head" or mispelling words, especially of similar sounds) more often than people with visible perception.

I enjoy writing emails? Would I prefer to write code? Probably. However, even code is not the most productive thing. To paraphrase on what an article I read said the most productive thing a businessman makes are crucial decisions which radically change the way your business operates. The analogy to the FOSS world is that people who only write code (even exceptionally good code and a lot of it) are not as productive as people who define a better strategy for their code and projects. If I have speactacular code which is available only from some directory on an obscure FTP server, it would not be as ideal as me deciding to have a decent homepage for it with a download link and an archive containing the version number in the filename, etc. Most people take it for granted, but I've seen many exceptions to even this rule.

Now take it further. Deciding to write a FAQ was a critical decision. Now writing it would be the easy and relatively brainless part.

2. I had to find a URL which more experienced developers would know by heart.

That is a misconception. I personally do know exactly one URL of the website by heart: "http://www.gimp.org/", ok, two: "http://www.gimp.org/tutorials/". Everything else is opening it in the browser and search for the appropriate link (which in this case is prominently in the menu structure). I do believe that this is the same for all developers not actively working with the site itself.

OK, my bad.

3. 10 minutes is much less time consuming that writing a bug-fix or an enhancement patch for the GIMP or for any other program. If it takes me 10 minutes to answer someone in a polite, friendly and encouraging way and he or she later become an active developer, then I may have "wasted" 10 minutes, but subsequently got hours and days of voluntary development in return.

Which alternative is better? You decide.

Well, if it were fun to answer these kind of obvious questions that two minutes researching on the gimp homepage would have solved then you'd have a real point. It is not fun though. To the contrary.

And frankly, we put a lot of effort into the source package to make it as easy to compile as possible. I firmly believe that the quality of GIMPs code is a lot better than that of a lot of other free software projects, mostly because especially Mitch and Sven have very strict guidelines for patches.

Then somebody comes and asks if Gimp is written in C/C++? I mean, come on. That is like asking "I want to become a computer scientist. How does a computer work?". It is just a painful question.

I know it's a stupid question, but believe it many people come to the Technion CS/EE/Math/Industry&Management/etc. departments without any seriuos programming knowledge. I once helped two people - a guy and a pretty girl - who never operated a spreadsheet - not even Excel, which is what we had on the Windows network.[1] And they were EE students in their 4th semester with decent or better grades. And some of them actually become decent or even very decent programmers or engineers. And the vast majority of them get infested with a lot of nearly useless knowledge, part of which as far as many EE graduates are concerned is understanding how every level of a computer works down to the semi-conductors.[2]

Where was I? Yes, I know it was a stupid question. But it does not specifically say so on the site very well. Do we have a technologies we use page and/or Lines of codes counts page on the site? I don't think we do. We should because some people are too lazy to download the source, just to get a question answered.

(I'm not saying any people who is friendly will become so, but the fact is we've deterred a great deal of potential contributors due to such behaviour.)

There are some easy things we can do to improve the communication with other people, no doubt about this.

[further good points snipped]

Bye, Simon

Regards,

Shlomi Fish

[1] - Not that I dislike Excel. It's an exceptionally good spreadsheet program. At least Excel XP, which has fixed most of Excel 97/2K's bugs, and added some nice (but not too critical) usability improvements. I don't know about more recent versions. It may have gone downhill.

Some of MS' Software is actually pretty or even very good. Too bad I cannot run it on Linux+KDE without virtualisation hacks. And no - I don't dual-boot. I either use OpenOffice.org (also pretty good), and

I won't comment about other MS Office software here, because it's getting off-topic.

[2] - if anyone wants I can give an offhand and highly inaccurate explanation how a Metal-Oxide-Semiconductor (MOS) transistor works. It'll probably have a few minus and plus signs wrong, though, but it doesn't matter. And I don't remember any of the formulae.

MOS transistors (a.k.a MOSFETs) are what most of modern CPU/etc. hardware is made of. They are cheaper than BJTs, (Bipolar Junction Transistors) consume less energy, but are also slower.

As I said on the IRC. "Been There. [in EE studies] Done That. Forgot a lot. Remember too much.".

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.

Hi,

On Thu, 2007-03-22 at 06:02 +0200, Shlomi Fish wrote:

Well, I don't believe spending 10 minutes writing an email is a waste. I spend more time on most serious emails. When I write emails I invest a lot of conscious effort writing them.

Does this mean that you are volunteering to handle the 5 to 10 bug reports that are coming in daily, as well as all the "stupid" questions on gimp-user and gimp-developer? If each of them takes you ten minutes to deal with, you aren't going to have time for anything else in your life.

It is IMO very important that each bug report is handled quickly and that all questions are answered. I can spend about half an hour per day on this. That is not an excuse for being rude, I am only pointing out that you are asking for too much. We should definitely improve our tone and it will probably help to spend a few extra seconds per request. But if ten minutes is the required amount of time that needs to be spent on a bug report or for answering an email, then I am out.

Even reading your mails takes way too much of my time. I definitely prefer a short text that comes to the point quickly. And you should reconsider your use of footnotes in emails. No, it doesn't improve the reading experience as it forces me to scroll up and down.

Sven

Maybe it worth gathering such a common questions in a FAQ and place the link to it at the main page of the gimp.org? Unless these common questions aren't answered at the usual place, they would be asked again and again.

Sven Neumann wrote:

But if ten minutes is the required amount of time that needs to be spent on a bug report or for answering an email, then I am out.

Hi, general comments:

The tone of the GIMP mailing list has improved dramatically over the years (long time lurker here) and I would assert that it is generally very reasonable.

However, language barriers can cause problems and special care should be taken when this is obviously the case. Also, it's easy to slip into "bad habits" that may just require a bit of extra self-control.

To that end, spending 10 minutes on email is simply a waste of time. Terse is acceptable (even preferrable to long and meandering) and needn't be rude. I suggest an internal triage, where appropriate: (a) Is it worth my time to reply? Can anyone else answer this? (b) Is my response genuinely helpful? (c) Can I mitigate a problem by replying?

For the email that instigated this, I found it to be unfriendly as well. The conversation basically went: "What language do you use?", "Figure it out yourself." I would say this fails my little triage test. If you think the question is foolish, treat it like the lunatic ranting on the corner: walk as far away as possible. Alternately, be concise, but helpful: "It's written in C. You can get the source from ... -or- Just search for 'GIMP source code'." The goal would be to encourage the requestor to work forward, not to dissuade them from doing so.

Triage test (c) is simply damage control: If someone gets a rude message, a polite response from someone else gives people another place to focus.

There is a video called "How Open Source Projects Susvive Poisonous People" available on Google Video from a couple Subversion folks:

http://video.google.nl/videoplay?docid=-4216011961522818645

It's an hour long but is generally interesting. There are some valuable points not just from a "how to be friendly" perspective (which isn't always the answer, either) but also "how to keep a project on track". The section from 30:00-45:00 is probably most appropriate.

And a FAQ would certainly be helpful.

Regards, Chris

Akkana Peck wrote:

Maybe that's the intent -- to set up a gauntlet that weeds out any potential participants who might be lazy or thin skinned. If so, no problem. But if you actually want lots of new participants, then how other people perceive the project matters.

I don't think more automatically equates to better. It's important to discourage laziness. I'm happy enough if this discourages the lazy. One of the things that attracts me to this project is the level of attention to detail and enthusiasm from its contributors.

Is there a FAQ URL? There's nothing linked from the top level of gimp.org.

The developer faq is at http://developer.gimp.org/faq.html , linked from the menu.

And the FAQ doesn't have anything on the language(s) used to write GIMP.

If I write the answer, it'll be "why don't you download the sources and check for yourself?" :) Seriously, that's the best answer one can give. A contributor will need to do this anyway, the curious should be encouraged and for anyone else, the answer is irrelevant.

Except I'm hesitant to run off and register for the wiki so that I can add it, given that it's not linked from the main GIMP site, no one refers to it and the page itself discourages anyone from using it.

Then the situation is unlikely to be improved.

The out-of-date disclaimer should probably be left up until at least one of the veterans reviews the Q/As. The majority of the FAQ is up-to-date, though.

Michael Schumacher wrote:

We do have a list etiquette at http://www.gimp.org/mail_lists.html. I'd like to suggest that it is moved above the mailing lists, maybe it will be read more often then.

I recently submitted a patch to the gimp-web list addressing this page. I added a link to the etiquette section below. I considered moving the etiquette section above the mailing lists but didn't want to put the page's primary information at the bottom! I also added a reference to the FAQ in the wiki.

Maybe we should advertise it a bit more - standard gimp.org message footers, anyone?

I think this is a very good idea. We should also link to the FAQ directly. We could also utilise the monthly list subscription reminder.

In addition, I think that the list etiquette should point to the "smart questions" guide: http://www.catb.org/~esr/faqs/smart-questions.html

Yes, I know that some think that this document is rude, but it has been incredibly useful for me. I always go back and read it when I find myself asking too many simple questions per time frame.

I think that it's going to seriously put off anyone who's still not adjusted to free software culture. I'd much rather we have our own version that concisely and sympathetically addresses the same points. It could go on the mail_lists.html page. I thought I'd included something already in the patch, but it looks like I forgot about it.

Davidm

Hi Simon!

On Wednesday 21 March 2007, Simon Budig wrote:

Shlomi Fish (shlomif@iglu.org.il) wrote:

Actually I also think it was too rude. Let's analyze it:

[...]

1. You didn't say "hi".

Oh, come on. A lot of the mails on mailinglists don't include a greeting if quoting something. I've never perceived that as *rude*.

It isn't normally, but it was in the context of that laconic email.

2. You phrased it as a question that implied the original poster should have thought abuot it himself, instead of giving an answer.

Oh, come on again. It is not unusual to formulate a suggestion in terms of a question. To pose this as rude is IMHO blown way out of proportion.

Yes, but by phrasing it as a question, the OP was essentially accused of not thinking about it before.

I really don't get why this discussion sparked from this specific mail. Please also keep in mind that most of us are *not* native speakers and discussing stuff in this linguistic nuances is probably a wasted effort.

As said, it is a general trend we noticed here. This email was just an instance of it and we found it necessary to discuss it.

BTW, I believe there had been an improvement here, but it is still not enough.

[...]

However, I believe Alpár's and Joao commentary was induced by the general trend of treating people on this list (and potential future contributors) rudely or impatiently. I've noticed this general trend here too after someone made me more aware of it.

Funny, my impression is, that it got better in the last few months.

It did.

I believe the GIMP could have been much better off today, if it weren't for all the antagonism that the developers' have created. I mean, sure after Spencer Kimball and Peter Mattis left the project and most of the other original developers left to work on GNOME, very few developers were left. But since then the community of FOSS developers grew by leaps and bounds, and there shouldn't have been any problem finding much more potential developers than we have today. There are plenty of fish in the sea.

I am concerned that this might not be exactly true. I don't have specific numbers, but my impression is, that it is way harder to sort the wheat from the chaff nowadays. In the beginning of the GIMP the people who a) found the GIMP, b) bothered to subscribe to the mailinglist, c) expressed interest in contributing generally already were enthusiasts about free software. They used stuff like e.g. slackware to convince their boxes to boot into linux. They were editing textfiles to get an internet connection. They had a thorough understanding of their system. This is no longer the case today. I mean, I am teaching stuff at the CS department of our universities and there really are students here who never did any programming and/or are annoyed if they have to. I mean, WTF?

Granted, the pool became bigger, but the amount of fish in it did not increase in the same proportion. And there are a lot more projects fishing around in there.

I am not sure if this is a fair description, I probably sound a little bit like a grumpy old man. Not sure what to do about this though... :)

Well, you're somewhat right. But other projects do not seem to have a problem finding developers. Inkscape has them. Subversion has many of them. While the "hackerdom" level of the open source people has decreased somewhat, we still have many potential B.Sc./B.A/B.E. graduates who contribute to FOSS who can program in C on Unix. Or there are many enthusiastic high school or undergraduate students who learn a free Unix clone on their own, and can do enough programming. So not all are bad.

Many projects are propsepering because they can find many developers. Granted, a lot of them are easier to program for than the GIMP, but most of them are also demanding.

And I think even they had it pretty easy. I started programming and computing in 1987 with the PC XT ROM BASIC and DOS, when I was 10 years old. I think modern kids who start out today with Linux, still haven't suffered enough. However, I talked with a woman on the IRC, who started programming with IBM 1401 ( http://en.wikipedia.org/wiki/IBM_1401 ) assembly, and has used UNIX since AT&T UNIX Revision 6. (When it still printed on paper.) Now this is suffering. ;-)

Let's look at Inkscape for a counter example. They have been around for a much shorter time than the GIMP, but have made remarkable progress, because the atomosphere they have is much better. If they could do it, why can't we? Only because we reject potential developers.

I believe that "reject" is the wrong word here, because it implies that we'd do this on purpose which is in general not true. We do have a habit of expecting a lot from patches (look at the number of iterations some patches go in bugzilla)

That's not exclusive to the GIMP. I sent some patches to Subversion, too and it took me several iterations. They were rejected for such trifles as incorrect style, or trailing whitespace. I had to write a detailed commit log, and write the system tests in Python (where the initial test cases posted to the bug tracker were in Bash).

When patching the core perl5 documentation, I had to remove trailing whitespace, correct typos or punctuation, and fix phrasing according to the input of the more experienced developers. I also had to handle some "This patch sucks! The documentation is good enough." attacks.

but in general I believe that even the original patch author will agree that the result is way better than what was originally submitted. We also have the habit of expecting more than half-baked ideas when someone comes up with an idea and sometimes ideas are probed a lot before a developer admits that it might be a good idea.

It is good to have several such iterations if the patch is not good enough. However, we should do it in a friendly and supporting manner.

I guess that these intentions do not always make it through to the person presenting the idea and they take it as a hostile attitude of the gimp developers (sometimes even "threatening" us with switching to other applications). This is the area where we probably can improve things a lot by being more careful with the language. However, the probing in itself is necessary and important for the quality of the Gimp.

[and regarding inkscape - I like the project a lot and I don't mean them any harm, but they lost me as a contributor even before I tried to communicate with them - 430 source files in a single directory is a good way to do this, hopefully they will improve there.]

Inkscape also lost me as a contributor (at least temporarily) because when trying to fix a problem I encountered in the bugzilla, I could not understand where in the code it happened. Then, after a while, a different developer (probably more experienced) wrote a patch and applied for it himself.

About your suggestions:

1. Create a page with some FAQs and canned responses in both HTML and plain text formats. I volunteer to prepare and maintain this page. I also get sick of reading more "You should change the name of the GIMP, it is an insult in English", "When is CMYK/16-bit/whatever support coming?", etc. questions, but I believe we can at least answer them politely.

Please add "I will switch to [whatever]" to that list...

Right.

2. Have a system of self-moderation. Let the messages of developers with a tendency to be rude and untactful pass through a small forward of "friendliness experts" for approval and correction. IF the experts are unhappy, they'll tell the senders to edit them and re-send them.

Note that I'm not necessarily suggesting we force it down the developers' throat, although it may not be a bad idea either.

I think it is a bad idea. We do have to be careful that Gimp stays fun for ourselves. Putting ourselves in a self-surveillance-corset is a great way to kill the fun IMHO.

OK. I suppose we can send such notices, in private mail, after such an insulting message is sent, to have the poster of it be more aware of it, and to pay more attention next time.

3.

[snipped - that was IMO not necessary]

4. Otherwise have the developers pay attention and try to be as hopsitable, friendly and tactful as possible. Reading the Producing OSS book would be a good start.

I might give it a shot.

Thanks!

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets.

On Fri, Mar 23, 2007 at 09:42:03AM +0200, Shlomi Fish wrote:

Well, you're somewhat right. But other projects do not seem to have a problem finding developers. Inkscape has them. Subversion has many of them. While the "hackerdom" level of the open source people has decreased somewhat, we still have many potential B.Sc./B.A/B.E. graduates who contribute to FOSS who can program in C on Unix. Or there are many enthusiastic high school or undergraduate students who learn a free Unix clone on their own, and can do enough programming. So not all are bad.

Many projects are propsepering because they can find many developers. Granted, a lot of them are easier to program for than the GIMP, but most of them are also demanding.

As brought up earlier, claiming other projects have significantly more developers is simply untrue. Please stop spreading FUD. It would be helpful if you read prior parts of the thread before replying.

-Yosh

Manish Singh (yosh@gimp.org) wrote:

On Fri, Mar 23, 2007 at 09:42:03AM +0200, Shlomi Fish wrote: As brought up earlier, claiming other projects have significantly more developers is simply untrue. Please stop spreading FUD.

Oh, btw, "FUD" is another candidate.

AFAIK the term "FUD" has the very specific meaning of spreading (mis)information with the intent to hurt a project.

Since this obviously is not the intent here, the term "FUD" in this place is IMO wrong.

I thus propose the following simple rule:

- replace "FUD" with "misinformation" or "ill researched information".

Bye, Simon