Bug triage process for juju-core

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I really like the idea of using Critical for bugs which must be fixed
ASAP. Given Juju isn't a live service, those probably fit ok for
things which must be fixed for the next release. (Launchpad being a
live service that rolls out daily has slightly different requirements.)

I would like us to make the bug tracker actually useful, right now
there are a fair number of bugs marked "high" that are >6months old,
and a bunch of bugs that have been looked over, but don't have a
status or importance update.

I do think it is big enough that we actually need to make a team
policy of whether we want to actively maintain the bug tracker or not.
And then actually allocate resources (such as the on-call-reviewer) to
maintaining it.

John
=:->


On 2013-06-07 18:57, Danilo Šegan wrote:
> Hi all,
> 
> We are starting up with on-call reviewers doing bug triage as
> well. I've done an initial round going over ~30 oldest open bugs
> and 5 newest untriaged bugs.
> 
> I've also made an attempt at bug triaging guidelines:
> 
> 
> https://docs.google.com/a/canonical.com/document/d/1_XMfxKpySqy3bzM7oK3pYFWYvsll-6kMN85AM4kOG-o/edit#heading=h.a685atm1ob
>
> 
> 
> Only now I see that I can't set the document to be publicly
> viewable but editable by anyone in Canonical.  I plan to move it to
> a wiki page soon (or anybody else can do that).
> 
> 
> At this time, I am trying to define 'Critical' as something that
> needs immediate attention (drop everything, solve this) and 'High'
> as something that needs to be worked on asap (but does not require
> you to drop anything in progress).
> 
> I am pretty sure that people will have different opinions on these 
> topics, but I wanted us to get started, and having some base
> definitely helps.
> 
> In that vein, I've retriaged old bugs, and I suggest we keep doing
> that: if everybody does 30 open bugs (and records their progress
> towards the bottom of that google doc), we can get to a usable
> 'High' pile in a week or so.  For instance, I've done all the bugs
> that have their ID numbers in the six-digit territory (so, all bugs
> < 1000000).
> 
> I haven't bothered defining other priorities, or restricting their
> use like Launchpad team used to do.  I simply don't care enough
> about non-Critical and non-High bugs, but feel that we've got the
> bugs reasonably under control (or can get there easily) that we can
> leave users with the option of using different scales of
> non-importance :).
> 
> 
> A couple of problems I've hit:
> 
> - juju-project is not very usable since it includes some, but not
> all of our juju-core related projects; it also includes extras that
> we do not necessarily care about right now - juju-core team does
> not have sufficient permissions on at least goamz and goyaml
> projects to set all the statuses, milestones and such - it would be
> good to work towards a consolidated triage policies for all of the
> juju teams - juju/juju-core bugs and triage: I am sure it's going
> to be very confusing to our users for all the bugs that affect both
> projects (I wonder if it makes sense to change at least the display
> name for "juju" to "juju-python" or similar)
> 
> Thoughts, comments?
> 
> Cheers, Danilo
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG1mygACgkQJdeBCYSNAAP2hgCfeYilCuXMuZtHNONSSw7O7rUY
IAEAn0L9ajBLMF+0kfQGT0UGPLUWeuFj
=stW7
-----END PGP SIGNATURE-----