<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: What to do with features nobody wants to implement</title>
	<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/</link>
	<description>Just another GNOME Blogs weblog</description>
	<pubDate>Thu, 28 Aug 2008 12:32:34 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Anonymous</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-140</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-140</guid>
		<description>I think discouraging people from giving feedback is a bad idea. Instead, why not mark the bug as UNLIKELY, with a note explaining that it is unlikely to be implimented without a patch.</description>
		<content:encoded><![CDATA[<p>I think discouraging people from giving feedback is a bad idea. Instead, why not mark the bug as UNLIKELY, with a note explaining that it is unlikely to be implimented without a patch.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hans Petter Jansson</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-141</link>
		<dc:creator>Hans Petter Jansson</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-141</guid>
		<description>The bugzilla priority field is severely underrated. I use it to mark things according to how important I think they are (useful to more people -&gt; more important). If you sort your bug list by priority, the "clutter" requests should then sort towards the bottom.&lt;p/&gt;As an added bonus, others browsing bugzilla get an impression of what is being/will be worked on.&lt;br/&gt;</description>
		<content:encoded><![CDATA[<p>The bugzilla priority field is severely underrated. I use it to mark things according to how important I think they are (useful to more people -> more important). If you sort your bug list by priority, the &#8220;clutter&#8221; requests should then sort towards the bottom.
<p />As an added bonus, others browsing bugzilla get an impression of what is being/will be worked on.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Schroeder</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-142</link>
		<dc:creator>Jeff Schroeder</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-142</guid>
		<description>I agree 100% man. Very nice post!</description>
		<content:encoded><![CDATA[<p>I agree 100% man. Very nice post!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bkor</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-143</link>
		<dc:creator>bkor</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-143</guid>
		<description>Suggest to change the target milestones of such bugs to 'Future'. Then add a standard comment that clearly says the bug will receive little attention because all the developers are focussed on other things.&lt;p/&gt;Do say you would appreciate someone writing a patch for it.&lt;p/&gt;If you never want to implement an enhancement, also clearly state that and mark the bug wontfix; the person requesting it is of course free to implement it, but that makes it clear it will never be committed (avoids frustration).</description>
		<content:encoded><![CDATA[<p>Suggest to change the target milestones of such bugs to &#8216;Future&#8217;. Then add a standard comment that clearly says the bug will receive little attention because all the developers are focussed on other things.
<p />Do say you would appreciate someone writing a patch for it.
<p />If you never want to implement an enhancement, also clearly state that and mark the bug wontfix; the person requesting it is of course free to implement it, but that makes it clear it will never be committed (avoids frustration).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-144</link>
		<dc:creator>Alan</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-144</guid>
		<description>I think the clutter bugs are best left open but I would say that since I've been known to file a fair few requests which fall into that category.  These requests should be marked with low priority and polite disclaimers that they may never be implemented and the standard comment about 'patches are welcome'.  &lt;p/&gt;if existing infrastructure doesn't handle things perhaps a "blueskies" keyword is needed, or seperate bugstate (or mabye expand NEEDINFO to include need patches and developers for UNLIKELY to ever happen)&lt;p/&gt;It is all too easy to forget that it is an effort for users to bother providing feedback and having requests marked as WONTFIX without much explanation can be very discouraging.  (Having bugs marked as duplicates without copy relevant extra information across to the other bug report can be quite frustrating too.)</description>
		<content:encoded><![CDATA[<p>I think the clutter bugs are best left open but I would say that since I&#8217;ve been known to file a fair few requests which fall into that category.  These requests should be marked with low priority and polite disclaimers that they may never be implemented and the standard comment about &#8216;patches are welcome&#8217;.
<p />if existing infrastructure doesn&#8217;t handle things perhaps a &#8220;blueskies&#8221; keyword is needed, or seperate bugstate (or mabye expand NEEDINFO to include need patches and developers for UNLIKELY to ever happen)
<p />It is all too easy to forget that it is an effort for users to bother providing feedback and having requests marked as WONTFIX without much explanation can be very discouraging.  (Having bugs marked as duplicates without copy relevant extra information across to the other bug report can be quite frustrating too.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Clinton</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-145</link>
		<dc:creator>Jason Clinton</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-145</guid>
		<description>He didn't call Gnomies "fucking idiots". Read it again. He called anyone who uses "usability" as a excuse for needed features not being implemented instead of "not enough programming resources" a "fucking idiot". The former is a dangerous practice that has been increasing in the Gnome project; the later is the responsible (and correct) response to a feature not being implemented.</description>
		<content:encoded><![CDATA[<p>He didn&#8217;t call Gnomies &#8220;fucking idiots&#8221;. Read it again. He called anyone who uses &#8220;usability&#8221; as a excuse for needed features not being implemented instead of &#8220;not enough programming resources&#8221; a &#8220;fucking idiot&#8221;. The former is a dangerous practice that has been increasing in the Gnome project; the later is the responsible (and correct) response to a feature not being implemented.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Weepie</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-146</link>
		<dc:creator>Bill Weepie</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-146</guid>
		<description>I have to admit that I'm one of the people that filed a bug requesting a few of those video game audio formats.  I agree with the other commenters here that such a request is kind of out there, and extremely low priority.  Setting to UNLIKELY with an invitation to submit a patch sounds like a reasonable enough way to prevent them from cluttering up the Bugzilla too much.&lt;p/&gt;Even though Gameboy audio (And SNES, Playstation, N64, etc etc..) support would be "great to have," I'd rather the devs work on more important things that actually effect a measurable number of people.</description>
		<content:encoded><![CDATA[<p>I have to admit that I&#8217;m one of the people that filed a bug requesting a few of those video game audio formats.  I agree with the other commenters here that such a request is kind of out there, and extremely low priority.  Setting to UNLIKELY with an invitation to submit a patch sounds like a reasonable enough way to prevent them from cluttering up the Bugzilla too much.
<p />Even though Gameboy audio (And SNES, Playstation, N64, etc etc..) support would be &#8220;great to have,&#8221; I&#8217;d rather the devs work on more important things that actually effect a measurable number of people.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-147</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-147</guid>
		<description>Jason - the catch is, "needed features" is a mostly subjective term. Anyone can request some new features without regard to how they should fit into the existing UI - is it wrong to turn down such a request on grounds that the benefits from adding it isn't worth the complexity it adds to the interface?</description>
		<content:encoded><![CDATA[<p>Jason - the catch is, &#8220;needed features&#8221; is a mostly subjective term. Anyone can request some new features without regard to how they should fit into the existing UI - is it wrong to turn down such a request on grounds that the benefits from adding it isn&#8217;t worth the complexity it adds to the interface?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: misGnomer</title>
		<link>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-148</link>
		<dc:creator>misGnomer</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/uraeus/2005/12/14/what-to-do-with-features-nobody-wants-to-implement/#comment-148</guid>
		<description>"Now I realize of course that the lack of gameboy audio format support makes GStreamer useless for people like Linus, and that we are fucking idiots for not diverting resources from for instance improving VoiP support over to work on supporting such formats.."&lt;p/&gt;Attitude and (intentional?) miscomprehension are always such a potent combination.&lt;p/&gt;Jason C. above summed up the issue pretty well.&lt;p/&gt;And to Simon, in that context "needed features" probably referred to making commonly used/needed features (e.g. provided by hardware such a printer) available. Sane defaults are wonderful and provide usability; ability to access more advanced options is also part of usability. Someone said it much better but there is no such thing as clear majority because most people belong to some minority as well (i.e. most need some feature outside the ultrasimplified default feature set).&lt;p/&gt;This doesn't mean going all out the KDE way but widening the feature set in a thoughtful manner.&lt;p/&gt;GStreamer being a non-GUI framework has different "usability" priorities and adding support for obscure formats probably isn't a priority at this stage.</description>
		<content:encoded><![CDATA[<p>&#8220;Now I realize of course that the lack of gameboy audio format support makes GStreamer useless for people like Linus, and that we are fucking idiots for not diverting resources from for instance improving VoiP support over to work on supporting such formats..&#8221;
<p />Attitude and (intentional?) miscomprehension are always such a potent combination.
<p />Jason C. above summed up the issue pretty well.
<p />And to Simon, in that context &#8220;needed features&#8221; probably referred to making commonly used/needed features (e.g. provided by hardware such a printer) available. Sane defaults are wonderful and provide usability; ability to access more advanced options is also part of usability. Someone said it much better but there is no such thing as clear majority because most people belong to some minority as well (i.e. most need some feature outside the ultrasimplified default feature set).
<p />This doesn&#8217;t mean going all out the KDE way but widening the feature set in a thoughtful manner.
<p />GStreamer being a non-GUI framework has different &#8220;usability&#8221; priorities and adding support for obscure formats probably isn&#8217;t a priority at this stage.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
