-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/2012 03:29 PM, Matthew Paul Thomas wrote: > Hi folks > > In my experience, once you have one ordered list of things to do, > every extra to-do list -- even a reordering of the existing list > -- adds confusion and forgetfulness about what you should work on > next. > > Currently we have five or six to-do lists for Ubuntu Software > Center.
> 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> > > 2. The "ca-escalated" bugs for Canonical's Consumer Applications > team. > <https://bugs.launchpad.net/bugs/+bugs?field.tag=ca-escalated> > > - This is somewhat understandable, because it extends beyond > Ubuntu Software Center alone. I'll work within Canonical to ensure > that that only time anyone needs to look at this list is during > dedicated CA team triage. I think it might be useful to do a weekly "ca-escalated" (short) triage call, just to make sure that everything on this list is really meant to be on this list, and that each one of these bugs has a priority set and an assignee. > > 3. The list of active merge proposals. > <https://code.launchpad.net/software-center/+activereviews> > > - Given how Launchpad works, this is unavoidably a separate > list. Indeed. It's an essential part of bug-fix flow. > > 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, 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!!) 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! > > 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). 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). 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). > > 6. Occasionally a sixth list appears, when someone assigns bugs to > the software-store-developers team as a whole. > > - I propose that we have a policy of never having any bugs > assigned to any team as a whole, because they look like they're > showing up on someone's to-do list when they aren't. (I have been > informally implementing this policy already.) If these bugs are added to a blueprint, then they are tracked as assigned to the team. A good example of this is an open-ended task like "improve performance", which tends to occur in stages and is often worked on at various points by different people. I think it's appropriate that this kind of bug is assigned to the team. The good news is that if these are in a blueprint they show up as work items, and they do not get lost in the sea of bugs. The problem is when this happens outside of blueprints. Then, I agree completely, it's too easy to lose track of them. > > Does that look like a reasonable plan? Are there any other to-do > lists I've forgotten about? > 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!! mpt, thank you for writing this email and bringing up this issue! Cheers, Gary > Cheers > > _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/JUL8ACgkQunmw/J3CVNPZdgCgmSsuyUTrlLmFw9BBsNt8wuMI DIMAniBReMjPmLSQIg4JuAaXnXCD2QpT =oiJP -----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
