> > > 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 use-case. -C > > > >> > >> On 23 April 2016 at 09:51, Bill Skaggs <weskaggs@xxxxxxxxx> 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 > >> > 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 > 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@xxxxxxxxx> > >> > 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: gimp-developer-list@xxxxxxxxx > >> >> 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: gimp-developer-list@xxxxxxxxx > >> > 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: gimp-developer-list@xxxxxxxxx > >> 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: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
