On Wed, Sep 25, 2013 at 8:12 AM, John Arbash Meinel <[email protected]> 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
