On Mon, Sep 11, 2006 at 11:05:18PM +0100, Alan Horkan wrote:
I sometimes feel hesistant to close certain feature requests, or how similar things need to be to mark things as duplicates.
One of the requests I closed just today was for asking for Inkscape to use the platform native file chooser.
Agreed. This is a Gtk issue at heart.
The more general issue I am trying to deal with is how can I better know what bugs to close and make sure I dont go too far? It is always possible some developer somewhere will be inspired to add wacky and interesting features.
I would recommend a polite response something along the line of, "This falls outside the scope of what the current developers plan to work on. If you feel strongly that this should be included, you are welcome to submit a patch that implements the feature, and it'll be reviewed for possible inclusion."
In other words, rather than just outright saying "no", give them the thread of hope that it could be included, if only someone can take on the challenge of coding it.
For all of these iffy fringe features, developers may not be in 100% agreement whether the given idea could or couldn't be included in Inkscape, or even whether it should be on our roadmap, but I think none would have an issue with essentially telling the submitter, "For this one, first send a patch. Then we'll talk."
Of course, not everyone can code, but we need to clearly delineate that Inkscape is contributor-driven and thus is not going to be able to meet needs for which no contributors exist. I always like to emphasize that there are many non-coding ways to contribute, but for some features, it really does boil down to needing the code. Thus, the requestor could learn to code themselves, or work out some sort of trade with a coder.
Bryce