-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oh, and in case the sentiment did not come through in my previous reply, I just want to say that I very much agree with your point, mpt, and I also very much appreciate the thought and clarity you put into making it!! I am very sure that addressing this issue in the most effective way that we can will be a great help to our team. Thanks again! Gary On 06/01/2012 07:31 PM, Gary Lasker wrote: > 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/KO6YACgkQunmw/J3CVNMdSgCfUF3VDX2TEf6r4yP4CBAVWc/u xzoAoJdoiQiqGgqqJnVFjYGQwQAKaN1G =xLtT -----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
