software-store-developers team mailing list archive

[Gary Lasker <gary.lasker@xxxxxxxxxxxxx>]

-----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     :
> 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/JUL8ACgkQunmw/J3CVNPZdgCgmSsuyUTrlLmFw9BBsNt8wuMI
DIMAniBReMjPmLSQIg4JuAaXnXCD2QpT
=oiJP
-----END PGP SIGNATURE-----