I sometimes feel hesistant to close certain feature requests, or how similar things need to be to mark things as duplicates. There haven't been any complaints so I can only assume no one minds (although bulia has corrected some of my sloppier less accurate comments but some days you are tired and __it happens).
One of the requests I closed just today was for asking for Inkscape to use the platform native file chooser. Given how the Inkscape developers have already removed this mis-feature from the codebase I'm just hoping for agreement that it is impractical to do something like that on a per application basis and any future requests should be referred to GTK?
https://sourceforge.net/tracker/index.php?func=detail&aid=1550205&gr...
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, but it would be helpful if there was something the developers could or say to do to cut down on the guess-work when closing request for things which are likely to be beyond the scope of Inkscape.
Does anyone have an ideas about cutting down the quantity of duplicate requests? (I've always said anonymous requests put the barrier too low, and users should at least be interested enough to provide follow up information if needed.)
Should I start to carve out some kind of Anti-Roadmap in the wiki and try to explain some of the things which fall beyond the scope of Inscape?
Thanks in advance, back to trawling through the tracker for another while
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
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
On Mon, 11 Sep 2006, Bryce Harrington wrote:
Date: Mon, 11 Sep 2006 15:18:00 -0700 From: Bryce Harrington <bryce@...961...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Bug tracking and Closed feature requests
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.
There is I assume a shared interest and the long term goal of getting more people using and contributing to the software we all enjoy Inkscape, GTK, and many other associated libraries and wider platform.
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."
I do try to mention the usual patches welcome and put things into context. I do try to give users a good sense of what might realistically get implemented but having said that I did leave open a request for Microsfot XAML support. I suppose I could use the roadmap and the SVG specifications to exclude many more requests.
On file format support, SVG and PDF seem to be the primary vector file formats and PNG (and maybe JPEG?) for rasters are a necessity but everything else is dependent on outside contributors to improve and maintain (be they in the form of patches, libraries, or extensions using other applications). Is that a fair assesment?
(There are so many file formats in the gimp which many people have an expectation will be maintained. The gimp developers are responsible enought not to pull Firefox and chuck out the baby with the bathwater and are waiting to devolve a lot of these into seperate plugins not included by default. Making the core formats clear up front and requiring active maintainers helps aviod such sprawl happening to inkscape, the seperation provided by extensions helps too.)
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.
I do try to put things in terms of "Yes, but probably not..." to give things a positive spin. I find anonymous reports very frustrating because you dont know if anyone is even bothering to pay attention to the response.
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,
Inkscape has made so much progress the Roadmap could stand to be fleshed out some more.
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.
As soon as I sent the previous message it occurred to me that anonymous requests very much go against the ethos of engaging and encouraging contributors to get more involved.
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.
Have any of the Inkscape developers been asked to work for hire improving Inkscape? (Not including the Google Summer of code.) This seems to be something likely to happens later when smaller businesses take the plunge and switch to inkscape. I think most of the people requesting features at the moment would only be able to offer a donation as a gesture rather than enough to pay a developer for a few days work. Theories of end users clubbing together to fund development haven't ever panned out far as I know, but it is certainly a nice hope.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Open Clip Art http://OpenClipArt.org
On Tue, Sep 12, 2006 at 01:15:32AM +0100, Alan Horkan wrote:
On file format support, SVG and PDF seem to be the primary vector file formats and PNG (and maybe JPEG?) for rasters are a necessity but everything else is dependent on outside contributors to improve and maintain (be they in the form of patches, libraries, or extensions using other applications). Is that a fair assesment?
Yup.
(There are so many file formats in the gimp which many people have an expectation will be maintained. The gimp developers are responsible enought not to pull Firefox and chuck out the baby with the bathwater and are waiting to devolve a lot of these into seperate plugins not included by default. Making the core formats clear up front and requiring active maintainers helps aviod such sprawl happening to inkscape, the seperation provided by extensions helps too.)
Good point
Inkscape has made so much progress the Roadmap could stand to be fleshed out some more.
Yeah... I have wished to put some time into it, but just have been too caught up in other projects. It would be great if others could dive into it and remove outdated bits, and add some more relevant stuff. Hopefully we can get it back in shape by the 0.45 release.
Have any of the Inkscape developers been asked to work for hire improving Inkscape? (Not including the Google Summer of code.)
Yes
This seems to be something likely to happens later when smaller businesses take the plunge and switch to inkscape. I think most of the people requesting features at the moment would only be able to offer a donation as a gesture rather than enough to pay a developer for a few days work.
I don't think we want to get into the business of having donations cause reprioritization of work. It seems to work best when there is a full sponsorship for a large scope of work, such as happens with the GSoC. That'd take quite a pool of donations, but I think it could be made to happen.
Bryce
participants (2)
-
Alan Horkan -
Bryce Harrington