Juju Project Bug Triage Rules and Plan

[Curtis Hovey-Canonical]

On Wed, Sep 25, 2013 at 8:12 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> https://docs.google.com/a/canonical.com/document/d/1_XMfxKpySqy3bzM7oK3pYFWYvsll-6kMN85AM4kOG-o/edit#
>
> But I think it has some bits that are more concrete about how we
> should handle it.

I think of the two documents are complementary. The draft document has
a lot of description. It is all about Juju. My document is about
action...you can substitute Juju for another project and it still
works.

> One bit that we are missing is whether *all* development work should
> be based on a bug. We're pretty close to it, but I know it isn't true
> today. We do have Kanban vs Bugs, but neither is all that consistently
> updated (as in by each person every day).

I am -0 for creating bugs for every card on kanban. I only except bugs
that a change to my code will address. Not every card on kanban is
about landing a change to code. I think the simple streams work has a
lot non-code tasks for example.

Honestly. I don't want anyone doing more administra.I don't want to
see people creating bugs that cannot have a branch linked to them. I
don't want to see milestones created, then we change the expected
dates every week. I don't want to see bugs frequently rertargeted to
milestones because we were guessing at when the work will be done.

We could say we are committed to fixing all the high bugs in the next
6 months, and we have milestoned all the bugs we expect to address in
the next 6 weeks. We can be pessimistic about our 6 week
commitments,so that when we fix issues that are not milestoned,
everyone is pleased we were able to accommodate a late addition to a
milestone.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui