software-store-developers team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

3.  The list of active merge proposals.
    <https://code.launchpad.net/software-center/+activereviews>

    -   Given how Launchpad works, this is unavoidably a separate list.

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.)

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?

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.)

Does that look like a reasonable plan? Are there any other to-do lists
I've forgotten about?

Cheers
- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/JGBkACgkQ6PUxNfU6ecpb4gCgwh7sMxBspX7KVUgmKzcE3NuP
g/oAn0eBKTUxACLjAbQBnP/x/yPWWeVf
=8dcA
-----END PGP SIGNATURE-----