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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
