> 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
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
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 <weska...@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
> >> > have
> >> > been given and the discussion that followed them. Getting this
> >> > information
> >> > from a forum is usually much more difficult.
> >> >
> >> > It is quite reasonable to bring up enhancement ideas in a forum and
> >> > discuss
> >> > them there until they are reasonably specific and coherent, but once
> >> > that
> >> > 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 <pinh...@gmail.com>
> >> > wrote:
> >> >
> >> >> My point of view is: enchancements should be discussed on the forum,
> >> >> not in a bugtracker. Here is what DispCalGUI has:
> >> >> https://hub.displaycal.net/forums/
> >> >>
> >> >> 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
> >> >> bugtracker.
> >> >>
> >> >> 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: email@example.com
> >> >> List membership:
> >> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >> >> List archives: https://mail.gnome.org/archives/gimp-developer-list
> >> >>
> >> > _______________________________________________
> >> > gimp-developer-list mailing list
> >> > List address: firstname.lastname@example.org
> >> > List membership:
> >> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >> > List archives: https://mail.gnome.org/archives/gimp-developer-list
> >> _______________________________________________
> >> gimp-developer-list mailing list
> >> List address: email@example.com
> >> List membership:
> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >> List archives: https://mail.gnome.org/archives/gimp-developer-list
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list