[Gimp-developer] Have a gimp-developer intro page?
I've noticed there seems to be a great deal of negativity on this malling list that stems from people (myself included, unfortunately) attempting to make suggestions about topics that I get the impression have been discussed to death already. This used to be a problem for blender, as well (though nowhere near as bad as you guys get it). We solved it by writing a new developers introduction page on the wiki, which seemed to help our situation a lot. Having something similar, only maybe more of an intro to gimp-developers, might help here. Something linked to on the gimp mailing lists page. Another option would be to expand the gimp developer FAQ and link to it on the malling list page. Or perhaps there could just be a link to the task list page (is there an official one yet?) for 2.6. Content I can think of that would be useful for people signing up for gimp-developers include: * A notice to read the current task list, if there's an official one yet. * Certain commonly raised issues, such as yes, the devs do listen to users, or the task list is too long, so we're not taking more feature requests etc. Of course these are just things I've picked up on the list in my short time of actually reading it regularly. I'm sure there's a lot more. I'd be willing to put something together on the gimp wiki; I don't think it would be appropriate for me to actually write this sort of thing, but I could condense agreed-on content discussed here, or somethin. Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
It did kindof look that way. And I wasn't meaning to be offensive (certainly I don't support the kind of public attack that other guy is doing) so I guess I was giving unwanted advice; sorry about that. Good luck on the task list and getting things done for 2.6. Joe Sven Neumann wrote: Hi, On Mon, 2007-11-26 at 22:35 -0700, Joe Eagar wrote: You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea, We have this and other mailing-list where developers and artists can exchange their ideas. I am reading through lots of mails and forums each day to find out what GIMP users are saying and so do other GIMP developers. We are receiving a large amount of bug reports and enhancement requests through Bugzilla and we listen to them. We organize events where developers and users meet to evaluate the user requests and to plan the future of GIMP. What's the point of claiming that we would dismiss the suggestions of professional users? I am seriously offended by this accusation. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea, imho. Saying we cannot accept any new ideas until the existing ones are done is ok, but just dismissing them out of hand might deny you future access to their expertise (which can be fairly valuable). Raphaël Quinet wrote: snip - We have far more ideas than developers. We even have far more *good* ideas than developers. One way to reduce idea overload is to have some professional artists who really know how things work and can give really good feedback. This way you're not having a flood from all users. Though in gimp's place it sounds like such people would be more useful for evaluating planned features/improvements then actually coming up with new ones. Joe - The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later. - The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6. So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface. Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. Could you explain the reasoning behind this? Such feature requests are always a good thing, and listening to them is a sign of a user-centric development team. By listening to them I don't mean *implementing* them, but a steady stream of such ideas can be beneficial. Though I suppose suggesting it on IRC might be more appropriate then on the list. Is that what you meant? Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Martin Nordholts wrote: Hi Joe Suggesting a new feature without specifying how the algorithm behind it work is pointless because how could the feature then be implemented? There are way too many other things to use the sparse GIMP developer resources for than to research details of other peoples feature requests. Well people do it to me all the time with blender. . .I sometimes figure it out, and if I don't have time to develop it myself I'll try and tell some other dev how it works. And he also offered to show a video about it. Feature videos are really useful for reverse engineering; I don't understand why Sven said otherwise. You can tell a lot sometimes. Also it's not as if anyone *has* to devote time to figuring it out. Users will make many, many more requests then there will ever be time to code, much less research. Simply listening to the more popular or useful sounding ones will give devs an impression of what users really want, and even what they *need*. This can help formulate long-term plans, both for the project but also for individual devs who think that way. Such requests might not always be appropriate for a feature tracker, or even a mailing list (I think IRC is a good place to put forth these ideas). But they shouldn't be rejected out of hand, either. I'm not totally sure the best way to handle this; Blender has a functionality mailing list that kindof serves the purpose of random feature requests, but it doesn't work very well. Like I said, for unlikely or somewhat obscure features it seems to be best if users discuss them on IRC, then if a dev gets interested he can, oh I don't know add it to the feature tracker or something like that. Or if he's like me, he may think about these sorts of a features every once in a while, and in a year or two even implement a few of them. Note the difference between not listening to users and rejecting incomplete feature requests. We appreciate that you think GIMP is worth spending some on to help improving, but please don't take it personal if some of your suggestions are considered incomplete. Imho, an incomplete feature request is something like I want a tool to make healing brush better or something weird like that. I want a tool that automatically selects a source region for healing brush imho gives plenty of information, and if passed along to someone who knows the math behind it might even make sense to them. No one is obligated to research this, or even pay attention to it. All that matters is it sounds like a useful idea proposed by a user. And feature videos can help; I myself pieced 3d ray baking together from watching one modo video. It would be very appreciated if you took the time to research exactly how this algorithm is supposed to work. Regards, Martin Nordholts Well I don't have the time for that. :) Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
