OK guys, the tone of this discussion is distracting from the real problems we have and a possible solution.
and we do have problems that are in gtk (mainly on windows) and with a load of window managers that do not even implement the window hint that we are apparently the bleeding-edge users of for our docks. insight: I met with the openPrinting guys on tuesday and was telling them how this gtk+windows situation looked like a mini version of linux printing (_nobody_ can be bothered to work on print dialogs). the impression of one of the guys was that when it comes to gtk+windows, what you are talking about is GIMP and inkscape. these two seem to be the only clients (more than one way) that matter. what is not helping us is that outsiders expect this big application to have a big and active development team. to my surprise even the official commit stats come to that conclusion. meanwhile everyone who hangs around here knows that we have very limited resources. piecing all the contributions together I say we got about 3.7 full developers worth going on a at any given time. I am sure that the 1 million users who download GIMP for windows every month somehow expect that is was developed on windows. so the solution is not to ask the people who (and I am grateful for it) do their best to contribute now. the solution is to stop potential contributors having to find out by osmosis how they can help us. what we can do is be much more concrete on www.gimp.org and say on the home page: "Help wanted". This is eerily close to job openings at companies, but that is what we have. and similar to companies we have to 'sell' our needs a bit. show that new developers can work on a coherent package of work where they can make an impact, pretty soon. I think for instance Martin and Alexia discovered that over the last years and they have carved out their niche(s) where they are having a large impact. "GIMP is looking for an experienced windows XYZ developer who can really make a difference to our user experience on windows." I do not want this to be a high-maintenance thing like the SoC. The effort for the current contributors should be limited to: - coming up with a coherent package of work and requirements for the new contributor ("has to know XYZ libs and ABC algos") - write the help wanted add (if you do one a month, it may become NEWS on all those GIMP tracking sites) - help the new contributor with the bug numbers and where to start in the source ("oh, that is in gtk") - be really clear in what we want to achieve (I can help with that) - no further hand-holding another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone). --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture
Description: S/MIME cryptographic signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer