On closing old bugs

Scott Downe scott.downe at gmail.com
Wed Dec 4 08:20:45 PST 2013


A lot of the bugs I changed to mentor bugs were bugs that were valid but
not something that we needed to be working on, or that were in scope.
Similar to the icebox idea.

Some of the mentor bugs are actually harder than others, level 2 type bugs.

I think the term icebox might turn people away from doing it. Makes it
sound like we don't want it.

I just talked to Josh Matthews about this, and he said mentor bug doesn't
mean easy, mentor in combination with good first bug means easy. So we can
easily add a mentor to any bugs we want to icebox, which might increase our
chances of actually getting a pull request :)

If we use mentor instead of icebox, we also get exposure through bugs ahoy.

Another difference is a mentor bug needs an actual mentor on the line.

Just some thoughts.


On 4 December 2013 10:33, David Humphrey <david.humphrey at senecacollege.ca>wrote:

>  There's a thread happening on Mozilla's dev-platform list about what to
> do with old bugs.  I wanted to raise it in our context, because we've
> suddenly become good at triage again, with our weekly triage meeting.  In
> that meeting we're WONTFIX'ing or otherwise closing a lot of bugs.  One
> thing we've started to do is add "icebox" to the whiteboard for things that
> are valid, but aren't in scope for us to work on any time soon.  I think
> that practice is a good one, and we should consider doing two things:
>
> 1) Exposing the "icebox" list more prominently in our dev docs and for the
> community and new devs to see.
>
> 2) Making sure that things going in the "icebox" are things we'd
> review/land if they had a patch.  Otherwise, we should close them.
>
> If people have other ideas on how to keep our bug lists under control,
> please share them.
>
> Dave
>
>
> -------- Original Message --------  Subject: Re: On closing old bugs  Date:
> Wed, 4 Dec 2013 15:20:09 +0200  From: Henri Sivonen <hsivonen at hsivonen.fi><hsivonen at hsivonen.fi>  To:
> Lawrence Mandel <lmandel at mozilla.com> <lmandel at mozilla.com>  CC: dev-platform
> <dev-platform at lists.mozilla.org> <dev-platform at lists.mozilla.org>, Karl
> Tomlinson <moznews at karlt.net> <moznews at karlt.net>
>
> On Wed, Dec 4, 2013 at 7:15 AM, Lawrence Mandel <lmandel at mozilla.com> <lmandel at mozilla.com> wrote:
> > I would assert that if a bug hasn't been fixed in 10 years it probably isn't important enough to spend time on now. We can always reopen or refile if the issue becomes more pressing (by anyone's judgement).
>
> I disagree. As I said earlier, closing bugs by age is really bad for
> bug reporter motivation.
>
> Furthermore, old bugs may become worth fixing when the circumstances
> change (other browsers catch up) or the level of understanding of the
> issues changes. As an anecdote, within the last 7 days, I've written a
> patch for a decade-old bug that's only relevant to legacy sites in
> India, Armenia and potentially Georgia. That's a bug that Chrome devs
> felt worth fixing in Chrome just 5 years ago. Chrome is doing better
> than we are in terms of market share in those countries, so it might
> well be worth a tiny bit of effort to make the long tail of legacy
> sites work (for some definition of "work") so that there's no reason
> not to choose Firefox because of the legacy long tail. Also, having
> had the bug open for a decade provides useful information of the
> relative fringe nature of the issue in question and indicates that it
> doesn't make sense to put a lot of work in developing a more polished
> fix than the crudest hack that's known to work for Chrome.
>
> --
> Henri Sivonenhsivonen at hsivonen.fihttp://hsivonen.fi/
> _______________________________________________
> dev-platform mailing listdev-platform at lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-platform
>
>
>
>
> _______________________________________________
> Webmaker-dev mailing list
> Webmaker-dev at mozilla.org
> https://mail.mozilla.org/listinfo/webmaker-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.mozilla.org/private/webmaker-dev/attachments/20131204/efaaeb57/attachment.html>


More information about the Webmaker-dev mailing list