Papercuts remixed (was Re: What's the status of papercuts?)
tanstaafl at libertytrek.org
Wed Jul 11 11:19:57 UTC 2012
On 2012-07-11 5:09 AM, Ludovic Hirlimann <ludovic at mozilla.com> wrote:
> On 7/11/12 5:37 AM, Kent James wrote:
>> 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.
> 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?
I know I'm not a programmer so may be speaking out of turn, but...
Since the current bugs database is so huge (and there are probably a
*lot* of outdated/old/irrelevant bugs in there), whatever is done, it
should be really easy to find/work with these bugs... so, either an
entirely new bug DB, or at the very least a prominent tab in the current
system so people can browse just these bugs...
I'd start with area of the code/complexity (we want bugs that are most
likely to get worked on), then votes (we want ones that will have the
most positive impact on users), etc...
As for how many, again, I don't think we should start with 100 that are
going to be a lot of work, but... being able to start announcing lots of
long standing fixes, even if they are relatively minor, would be really
good PR (note what happened with LibreOffice when it forked) and would
also serve to attract more potential devs, since most people prefer
working on an active project rather than a seemingly dead one, so maybe
limit the total number of bugs under this new tracker to 100, but limit
the number of 'complex' ones to 10 or so, then have a way to prioritize
bugs from the old/main tracker into a queue, which will automatically
move them into the active tracker as others are closed.
More information about the tb-planning