software-store-developers team mailing list archive

[Gary Lasker <gary.lasker@xxxxxxxxxxxxx>]

-----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     : 
>> software-store-developers@xxxxxxxxxxxxxxxxxxx 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-----