-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Lasker wrote on 02/06/12 00:31: > > On 06/01/2012 03:29 PM, Matthew Paul Thomas wrote: > > ... >> I suggest that we work to reduce the number of extra to-do lists >> we have. >> >> 1. The bug list, which currently has about 54 % of bugs >> prioritized. >> <https://bugs.launchpad.net/ubuntu/+source/software-center> > ... > > Another to-do item (I guess it really is a kind of list) is general > bug triage. In order to keep the bug list in any kind of reasonable > state, we have to dedicate at least some time of each day to this. > It would be great to have more time to do this work, but often the > other tasks above tend to take precedent. > > I think one answer here could be to try to recruit community folks, > especially ones interested in bug triage, to help us out here. Or > try to recruit more community folks in general. The software-center > team LOVES their community members!!
I wonder if a tutorial screencast might help in showing how to deal with incoming bug reports. Or just a wiki page describing the next action for each bug status. (Ideally Launchpad would do this itself.) > ... >> 4. The lists of blueprint work items for the client and the >> server. >> <https://blueprints.launchpad.net/ubuntu/+spec/software-center-q-client> >> <https://blueprints.launchpad.net/ubuntu/+spec/software-center-q-server> >> >> - One possibility is to convert all these work items into bug >> reports, making them High importance if appropriate. The >> drawbacks are that it would take a fair bit of click-work, and >> they wouldn't show up on burndown charts. (Bugs vs. work items >> are the extreme in competing to-do lists.) > > In fact, all bugs linked to a blueprint *are* included and tracked > in all burndown charts, So we could convert the work items into bug reports, and then link the bug reports back to the blueprint? That would keep them on the burndown charts, though it would be even more click-work. > and I have found in past cycles that a blueprint is a very > effective funnel for prioritizing various sources into a single > to-do list. > > Check this blueprint: > https://blueprints.launchpad.net/ubuntu/+spec/consumer-p-software-center-enhancements > > > And take a look at the corresponding burndown chart (which > includes two other client-related blueprints): > http://status.ubuntu.com/ubuntu-precise/group/topic-precise-application-client.html > > > (hmm, looking at the image it's unfortunate to see that the teams > beautiful burndown performance last cycle has been obscured > somehow by the end-date for the blueprint being erroneously reset > to Jan of 2013!!) <http://launchpad.net/bugs/1002828> > In any case, I think you'd agree that that is a nice to-do list. > And you'll note that all bugs are included in the lists, along with > assignees and report titles and links to the bugs. It's pretty nice > imo! Of the ten bug tasks linked to those blueprints, four were High importance, three were Medium, and three were Low. They all got fixed. Why? I think you're saying it was *because* they were linked to the blueprint. But why were they linked to the blueprint? I don't know. For example, one of them is "Down key in search field doesn't select the first result" <http://launchpad.net/bugs/842711>. I reported it, and you fixed it -- and thank you, really. But I had triaged it Low for a reason: there were hundreds of bugs more important than that one, and some of them have been open for years. I'm not your manager or anything, but if the reason you fixed that one was "because someone linked it to the blueprint" -- and not something like "because I wanted to relax with a simple bug fix at the end of the day", or "because I was working in that part of the code anyway" -- then we have a prioritization problem. So I think that list is "pretty nice" only as an example of how bad multiple to-do lists are. ;-) >> 5. The 11 bug reports linked to the -q-client blueprint. One of >> these is currently High, some Medium, some Low, some Undecided. >> >> - I don't understand the selection of bug reports here. Are >> these just those bugs that happened to be mentioned during the >> UDS session? If so, could we re-triage and then unlink them? > > I put many of them here as I see them as good targets for work > during the cycle (this is, after all, the raison d'etre for > blueprints). I was in a Launchpad sprint in 2005 when Mark Shuttleworth turned up and said "Hi guys, I've been working on this new feature called Blueprint". The raison d'être was not for tracking work during a cycle, it was to track design and implementation of major features. It was always bad at this, partly because the design specification still had to be written elsewhere (so there was no advantage over bug reports), and partly because any feature not completed defaulted to disappearing off everyone's to-do list. Years later, work items latched on to Blueprint like a Rube-Goldbergian parasite. If Blueprint had never existed, but someone turned up today and said "I know, let's have a to-do tracker in Launchpad, separate from the bug tracker, and we'll track to-dos as lines of text in a free-form text field, with square brackets for the assignee, and link bug reports as well, and if anything doesn't get done for the current release, it's forgotten" ... they'd be laughed out of the room. > Most of these items involve at least some level of design work (as > opposed to crash fixes, etc.), and/or some UI changes (which means > they are usually tweaks and optimizations left over after the > previous cycle's UI freeze). Hundreds of bugs involve design work and/or UI changes. :-) > And as I mentioned above, a linked bug becomes a tracked work item. > This is very, very effective as a to-do list. > > I already mentioned to mvo that if he didn't agree with any of the > items there, he should feel free to take them off. I believe he > did this check. If you, however, feel that this isn't the right > list, please do feel free to add or remove items (or, probably > better, talk about them here so we can all decide together). > > ... Okay, here's a thought experiment. Eleven bug reports are currently linked to <https://blueprints.launchpad.net/ubuntu/+spec/software-center-q-client>: one High, three Medium, five Low, two Undecided. Now, imagine removing all of those, and replacing them with the top eleven bugs listed at <https://bugs.launchpad.net/ubuntu/+source/software-center>. If your response would be "But that would remove bugs that we really need to fix for 12.10!", then we're kidding ourselves about their Importance value, aren't we? Or about the importance of those bugs currently marked High. Or about both. Either way, it would mean triage is a waste of time. On the other hand, if your response would be "Sure, that would be fine", then linking bugs to the blueprint at all is redundant, except as a way of making them show up on burndown charts. We might as well just use the bug list -- after completing work items, fix as many important bugs as possible, instead of letting the burndown charts lull us into following Parkinson's Law. - -- mpt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/KTGIACgkQ6PUxNfU6ecrliwCfZuzBGFNMtkh5BfxcN2XGPxKv rqEAmgKmHc93PrmR3dnuYsPWhyQuHmL+ =qXPe -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~software-store-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~software-store-developers More help : https://help.launchpad.net/ListHelp
