Re: [Gimp-developer] Enhancement request policy

Spotted the lurker having a bad day :)

All of us play that part sometime. It's important to get over it and move
on, and not to send out emails to the group while upset. Being part of the
community means being social. Part of being social is not being a lurker. :)

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.

If it's debated (for example changing the name GIMP), then there is no
consensus. If it were obviously the right thing to do it would be in the
vision. If it's not, or is counter to the vision, we have to assess if we
need to change the vision. So it's still not a matter of users vs devs,
it's SOME users vs. one idea, one previous decision. People get cranky when
their idea is rejected, which is also why the soup tastes bad after only a
short time. Again read the FAQ for other good examples.

However, they do and the arguments ensue, which highlights my point
about devs not being receptive.

The devs are "receptive" they just don't comply or agree with every ask.
Again, the tautologies are clearly untrue. One idea from one users (even
backed by many users) does not constitute "All users" or even "users in
general". Each of us would like to think our ideas are great for the GIMP
project, but it's not always the case. One users most wanted feature is
another's terrible workflow bottleneck.

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.

Yep, but again, not all users agree with changing it back to the way it
used to be.
They did put in a work-around where if you forget to export, you can click
"take me to the export dialog" link in the warning message, and you're good
to go. So that's a decent compromise.

These sorts of clashes can be resolved much more easily by putting
configuration options in.

Sometimes. And also many are actually put in as options, which is why we
have things like the hotkey and input editors.

Sure it adds an extra test to be covered in your code but you are now
catering to both sides.

GIMP's development focus is on professional users who use GIMP for
graphics/photo work.
Bowing to every user request for a work-around makes a cluttered and
endless mess of the options, and an increasingly inconsistent UI.
It also may involve re-writing large chunks of the interface which may
clash with other parts.

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.

But, we have single window mode... so... ?
Seems like an example of GIMP devs listening to users, doesn't it?

The mission of GIMPShop was to bring a PhotoShop clone interface to GIMP.
Note how it's also a dead project at this point.

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

Constructive input is fine. Ranty emails about how no one listens are not
constructive input.
Also, just because it's constructive does not mean it's good for the
project, and is no guarantee that it will be accepted. People hear "no" and
take it personally. But it's not just "no" is it? There's always an
explanation behind it. So it's not even a matter of devs not listening.

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.

Users also only see the tip of the iceberg. From the FAQ:

"While working on functional specifications, Peter researched how various
features are implemented in applications with a partially matching feature
set (such as Adobe Photoshop), but the final design was made to help actual
users complete their tasks as fast as possible. This is exactly the kind of
approach to designing interfaces that we consider to be superior to merely
copying user interaction decisions."

For your idea, how much UI testing and UX diagrams did you do? Is your idea
even the best one? Is it better and faster in most workflows, or just in
your workflow? Like most things in life, if you can put together a good
mockup, get support from the community, and present a complete solution,
it's much more likely to be considered.

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!

My point is that devs DO listen to users. They do a lot more than not, so
the answer "no" is not them not listening, it's them rejecting the idea,
which has been rejected before for the same reason(s) in the past. As in
all things the strength of your case for the feature/change matters a lot.
People don't want to do any work though, they want instant satisfaction
without having delved into the problem any more than their own limited


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
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
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]