Excellent writeup. I agree with your conclusions -- we must reduce the number of open issues, not reclassify them. My vote has always been to close an issue that we cannot realistically fix in the next cycle, but I understand this has always been unpopular.
On Fri, Apr 18, 2014 at 5:47 AM, Curtis Hovey-Canonical <cur...@canonical.com> wrote: > NOW > > I moved a lot of bugs from 1.19.1 to 1.20.0 to make it easier to see > out immediate priorities. If we fix a bug in a future milestone I will > retarget it to the current goal. The intent is to make is clear what > must be fixed verses issues that may be fixed. > > Their are about 20 issues I *think* need to be resolved that will > define 1.19.1 features and fixes. I hope to release 1.19.1 next week. > > There are about 50 bugs targeted to 1.20.0. This is 2 weeks of bugs. > We can expect more bugs as users try the new features. So we are > really 3 or more weeks away from 1.20.0 We can anticipate 1.19.2 and > 1.19.3, maybe 1.19.4 before .1.20.0 > > FUTURE > > We fix about 25 bugs a week. Many bugs are fixed a couple days after > we discover them. I think our milestones have a capacity of 20 issue, > with room for another 5 added as we fix new bugs. > > We fixed about 400 bugs in juju-core and its libraries in the last 6 > months. That is more than half of all bugs ever fixed in the project. > Well done. However, only 100 of those bugs were known when we planned > the cycle; 3 out of 4 bugs are fallout from improvements or escalated > issues from our past. Developers are reporting many of the fallout > bugs a couple days after a merge into trunk. Users report the > remaining bugs after a release. > > Our 6 month cycle capacity is 100 high and critical issues. This a > problem for us because there are more than 250 High bugs in Lp. We > have 15 months of issues we want to commit to fix soon. We cannot. Our > goals change every few months; We, our stakeholders, and our users are > misinformed about our priorities and we cannot make plans based on the > high bugs. We need to lower the importance of more than half the high > bugs to make it clear that some issues will only be fixed by > opportunity or assistance. > > I am aware that we intend to have more engineers in the next cycle, > but they will need 3 or months of become competent. We can set no more > than 150 bugs as high as stretch goal. > > Lowering bugs to medium is not helpful. I have years of experience > with how projects use bugs in Lp. A medium bug in a large project is > not more likely to be fixed than a low bug. Opportunity doesn't > discriminate by importance. Bugs classified as medium importance are > not likely to be escalated to high in the next cycle. Each cycle with > new priorities continues to leap ahead of the medium bugs. > > If lowering the importance of our bugs is a political problem, we can > create a milestone call "horizon" that has just the bugs we expect to > fix in the next 6 months. The unscheduled high bugs will violate the > intent of scheduling our commitments. In reality the unscheduled bugs > will linger and likely be demoted to Low as interest in them wanes. > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
