Maybe we can create a meta bug on bugzilla and ask for everyone to add its bug to it. Then some "dictator" review it and remove all the bugs that don't seems to be relevant.<br><br><div class="gmail_quote">2012/7/11 Ludovic Hirlimann <span dir="ltr"><<a href="mailto:ludovic@mozilla.com" target="_blank">ludovic@mozilla.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 7/11/12 5:37 AM, Kent James wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/8/2012 10:49 PM, Chris Ilias wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In late March, Blake sent an email listing UX priorities, including papercuts. If I do a search for TB and mailnews core bugs with [UXprio] that are fixed since March 24, I only get one bug (508776). Has there been any priority given to those bugs?<br>

</blockquote>
I've often been concerned about the lack of attention within Thunderbird to long-standing bugs myself, and that also seems to be the source of a lot of the negative energy that sometimes surrounds the project. But honestly, I don't have a good feel for how important that is. I do know that some individuals have a lot of passion and frustration around certain unfixed bugs, and can generate a lot of negative energy over that issue.<br>

<br>
But let me propose an idea. What if we were to make a list of well-recognized bugs (not enhancements) in Thunderbird, and make that the focus of an initial effort for the developer community that is starting to gel around Thunderbird? That would go against the conventional wisdom of course that developers are mostly interested in jazzy new features, but perhaps being different could start to build some positive energy. I could imagine trying to develop a list of a certain number of bugs (not enhancements), and set the goal of fixing them all in some period of time.<br>

<br>
So as an example, we could develop a list of 100 Thunderbird bugs that at least 3 people are willing to vouch for (with a limited number of vouchers per person, and perhaps some vetting by a benevolent dictator), and recruit a group of community developers to tackle those in a year.<br>

<br>
Count me in, if other people are also willing to be involved.<br>
</blockquote></div></div>
I' think we'd be able to get a lot of interest if we did that. Now let's be practical, how do we cherry pick these 100 bugs , based on age, votes , area of the code ?<br>
<br>
<br>
Ludo<br>
count me in on that one<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
@lhirlimann on twitter<br>
<a href="https://wiki.mozilla.org/Thunderbird:Testing" target="_blank">https://wiki.mozilla.org/<u></u>Thunderbird:Testing</a><br>
<br>
my photos <a href="http://www.flickr.com/photos/lhirlimann/collections/" target="_blank">http://www.flickr.com/photos/<u></u>lhirlimann/collections/</a><br>
<br>
<br>
</font></span><br>_______________________________________________<br>
tb-planning mailing list<br>
<a href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/tb-planning" target="_blank">https://mail.mozilla.org/listinfo/tb-planning</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Vincent (caméléon)<br><br>