Re: [Gimp-developer] Enhancement request policy

On 29 April 2016 at 13:52, C R <cajhne gmail com> wrote:
My experience is that GIMP developers don't care what any user would
like to have.

Clearly untrue. We have the Unified Transform Tool, hardware acceleration,
Mypaint brush engine, and (up to) 64bit colour depth, and linear light
blending modes to look forward to in the next release, the freakishly
awesome Handle Transform tool, a proper on-canvas warp-tool, and so so many
more awesome things that users (including myself) have been asking for, and
anxiously awaiting.

There are things that I've asked for that didn't get implemented, but the
minute I start feeling bad about GIMP, and where it's going, or that one
thing I consider a priority over all others, I take a step back and and go
use other image editors for a while. I'm usually back to GIMP within a day
or so. :)

Better yet, if I think my idea is really good, I could go about getting more
of the community behind it with mockups and hanging out in the irc channels
and asking/answering questions. Sitting silent on the gimp-developer mailing
list and only poking my head up to offer up some ill-timed tautological
criticism does zero good for anyone, I've found.

Spotted the lurker having a bad day :)

There are some topics that just go round and round, which is why you will
find devs (and the community) going with a previously established answer.
Everyone's really sick of arguing about these things, and you can tell right
away witch ones they are, because they are in the FAQ on, and you
can feel the tension around the question and answer like a thick soup. No
one wants that soup, so generally we send it back when someone offers up
another helping of the same. :)

The general response is "we have previously decided that we want to do
it like this and we aren't interested in how the end user might find
something useful".

Ah "The End User". One end user's "might find something useful" is another
user's horrendous workflow bottleneck. If it was previously decided on,
there's likey a good reason for it. Could probably ask what the reasons are
for enlightenment.

You say that noone wants that soup and are sick of arguing it, but
surely the logic follows that if the users DIDN'T want it, they
wouldn't keep bringing it up.
However, they do and the arguments ensue, which highlights my point
about devs not being receptive.
A good example of this where it is not just one user is the
export/save as, which can be followed in the list history.
These sorts of clashes can be resolved much more easily by putting
configuration options in.
Sure it adds an extra test to be covered in your code but you are now
catering to both sides.
Another historical example is the single window mode and how popular
GimpShop was when it came out and how long core devs resisted before
implementing it.

This is in stark contrast to most of the other open source projects
that I work on that gladly take constructive input.

GIMP is a huge program with lots of end users, of which every one has their
own priorities, workflow preferences, etc.
GIMP also has very few developers, so a set list of priorities matter all
the more.

There seems to be a more aggressive stance here though on what are
priorities and what is just denials.
You don't see a response that often saying "thats an interesting
proposal for our UI but we are focussing on this core algorithm right
now so it will have to go on the back burner".
You are more likely to get an argument about the idea and how it
doesn't fit with the vision.

Thanks to everyone who works on GIMP. The current batch of new features in
trunk are going to make waves in the community. It's a tremendous gift, and
should be treated as such.

My 2p

Having said all this, you make a good point about all the new features
and it is much easier to complain than add these features!

On 23 April 2016 at 09:51, Bill Skaggs <weskaggs gmail com> wrote:
The great advantage of the bug-tracker is that it allows requests to be
handled in a structured way.  It is easy to find specific types of
enhancement requests in the bug-tracker and examine the priority they
been given and the discussion that followed them.  Getting this
from a forum is usually much more difficult.

It is quite reasonable to bring up enhancement ideas in a forum and
them there until they are reasonably specific and coherent, but once
has happened it is helpful to have an enhancement request created in the
bug-tracker.  If the developers don't like them, they can always be
classified as WONTFIX or NOTABUG.

On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow <pinhuer gmail com>

My point of view is: enchancements should be discussed on the forum,
not in a bugtracker. Here is what DispCalGUI has:

Mailing list is not exceptionally convenient for many people (myself
included. I just mailed topic starter instead of mailing to the list
thinking that replying to mail will get it done. I now pressed "reply
to all") but may be still better than discussing enchancements in

Imgaine that every user wants something new. Because of number of
users being magnitudes larger than number of developers (who are not
paid) and those willing to contribute the project is guaranteed to
drown in requests.

Bugtracker is for developers and they should pick doable tasks from
forum themselves.
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]