Papercuts: status and a top 10 list from the wiki
acelists at atlas.sk
Thu Dec 27 21:33:51 UTC 2012
-------- Original Message --------
Subject: Re: Papercuts: status and a top 10 list from the wiki
From: Wayne Mery (d531) <vseerror at Lehigh.EDU>
To: tb-planning at mozilla.org <tb-planning at mozilla.org>
Date: Thu, 27 Dec 2012 16:06:39 -0500
> As previously mentioned, I hope papercuts is just dormant and not dead.
> First, a recap:
> * jcranmer created
> * there was discussion on tb-planning
> * wayne created https://etherpad.mozilla.org/tb-papercuts
> * there was discussion on tb-planning
> * there was the summit in Warsaw 
> * dormancy
> Coming out of Warsaw I believe the plan was to revisit the ideas for
> papercuts and "the list". Shall we begin?
> "The list" is I think a qualified success, as suggested by ludo and as
> defined by "bugs on the list are getting fixed" (see "the list version
> 2"). I therefore have taken a second cut at "the list".
> Papercuts on the other hand has languished, I think because of the ramp
> up to Warsaw and getting TB17 out the door, and the fact that very few
> people have marked tb-papercuts in bugzilla.
> Papercuts' goals and process, as defined on the wiki, are worthy and I
> believe should be driven forward. Yes, there are process deficiencies
> previously discussed - for example lack of real voting process and
> integration to bugzilla, and lack of accessibility to the common
> man/woman. None of these issues are fixable given our current level of
> organization and volunteer commitment. But it's a light weight process,
> better than nothing, and there is (or was) substantial enthusiasm for
> the goals which might be summed up as, take a bug that some (informed?)
> group of people really cares about and fix it. Eight people quickly
> signed up to be on the fixing end of the effort of the 78 nominations.
> Indeed a few bugs got fixed, but very few bugs were "adopted" and then
> we somehow got lost .
> Next point ... it has been suggested that "the list" can be a
> replacement for papercuts. I disagree. "The list", as I have created it,
> is based largely on bugs with stability and dataloss potential, plus a
> small number of severe usability issues - for example bugs 66806,
> 487386, 511741, 522222. (and, as I am not "all wise", there no doubt
> some bugs that shouldn't be on the current list)
> Further, papercuts are mostly nuanced usage issues. I don't see papercut
> bugs surfacing organically via bugzilla or one person, or even a small
> group (unless we return to the system of "wanted" flags in bugzilla).
> Plus the mindset was it should be a list of bugs generated "by the
> people", versus a developer driven bug fix list. After all, one of
> major complaints of the post-TB2 era is not enough bug fixes driven via
> user input. (A complaint I don't entirely share, but I'm just one
> datapoint. Regardless, post-tb2 bug fixing was in fact informed by user
> input via thunderbird nomination flags. Whether the process worked well
> is a different matter.)
> I think what's on the wiki that jcranmer started is highly usable in the
> near term. And so I hope most everyone agrees papercuts is not and
> should not be dead. Better yet, I hope many of you make positive steps
> up to make it a working process! Mark your nominated and voted bug
> tb-papercut in bugzilla - I've done mine.
> As a parting related comment, http://tinyurl.com/cct9u34 is kent's top
> 10 from a previous post, in buglist form.
>  Warsaw, relavent comments from - as posted on tb-planning:
> - "Thunderbird projects and roadmaps" jcranmer 9/11/2012
> - "Summary of TB QA Meeting at Mozcamp" mconley 9/11/2012
> Action items
> * Get a list of people watching each TB component, and make sure we've
> got somebody with eyes on each one.
> * We're going to tackle the Papercuts list (10 bugs) to prove that we
> can deal with a list.
> * rkent(?) is going to send out a weekly status report on the Papercuts
> list, and what needs fixing, on what got fixed.
> * When the list is empty, or close to being empty, QA is going to
> develop a process for creating the list (which includes the facility for
> devs to indicate that a bug is too difficult).
> * We need to come up with some critiera for choosing bugs like the ones
> on Papercuts. Then QA / Support will build the list.
>  Papercuts, partial analysis (I stopped after examining 20 bugs at
> bug 11039 because 78 is too many to review):
> 78 nominated
> 38 voted and should be tb-papercut in bugzilla but only 6 are marked
> of the 20 I reviewed...
> 2 not marked papercut, but fixed - Bug 450302 Bug 650170
> 2 marked papercut + fixed - Bug 349547 Bug 739311
> 1 not marked but assigned/worked Bug 92165
> 15 not marked+not worked = NSA (no significant activity)
> tb-planning mailing list
> tb-planning at mozilla.org
Wayne, for me it is not clear what is the relation of the "Nominations"
table and the "papercut bug list" ("The bugs in this query have been
accepted as papercuts by the initiative"). The "papercut bug list" does
not contain the nominees that got votes. But I don't know what the
But at least I have fixed more of the nominated bugs than you counted :)
More information about the tb-planning