software-store-developers team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

Gary Lasker wrote on 02/06/12 00:31:
> 
> On 06/01/2012 03:29 PM, Matthew Paul Thomas wrote:
> 
> ...
>> 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>
> ...
> 
> 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!!

I wonder if a tutorial screencast might help in showing how to deal
with incoming bug reports. Or just a wiki page describing the next
action for each bug status. (Ideally Launchpad would do this itself.)

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

So we could convert the work items into bug reports, and then link the
bug reports back to the blueprint? That would keep them on the
burndown charts, though it would be even more click-work.

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

<http://launchpad.net/bugs/1002828>

> 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!

Of the ten bug tasks linked to those blueprints, four were High
importance, three were Medium, and three were Low. They all got fixed.
Why? I think you're saying it was *because* they were linked to the
blueprint. But why were they linked to the blueprint? I don't know.

For example, one of them is "Down key in search field doesn't select
the first result" <http://launchpad.net/bugs/842711>. I reported it,
and you fixed it -- and thank you, really. But I had triaged it Low
for a reason: there were hundreds of bugs more important than that
one, and some of them have been open for years. I'm not your manager
or anything, but if the reason you fixed that one was "because someone
linked it to the blueprint" -- and not something like "because I
wanted to relax with a simple bug fix at the end of the day", or
"because I was working in that part of the code anyway" -- then we
have a prioritization problem.

So I think that list is "pretty nice" only as an example of how bad
multiple to-do lists are. ;-)

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

I was in a Launchpad sprint in 2005 when Mark Shuttleworth turned up
and said "Hi guys, I've been working on this new feature called
Blueprint". The raison d'être was not for tracking work during a
cycle, it was to track design and implementation of major features. It
was always bad at this, partly because the design specification still
had to be written elsewhere (so there was no advantage over bug
reports), and partly because any feature not completed defaulted to
disappearing off everyone's to-do list.

Years later, work items latched on to Blueprint like a
Rube-Goldbergian parasite. If Blueprint had never existed, but someone
turned up today and said "I know, let's have a to-do tracker in
Launchpad, separate from the bug tracker, and we'll track to-dos as
lines of text in a free-form text field, with square brackets for the
assignee, and link bug reports as well, and if anything doesn't get
done for the current release, it's forgotten" ... they'd be laughed
out of the room.

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

Hundreds of bugs involve design work and/or UI changes. :-)

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

Okay, here's a thought experiment. Eleven bug reports are currently
linked to
<https://blueprints.launchpad.net/ubuntu/+spec/software-center-q-client>:
one High, three Medium, five Low, two Undecided.

Now, imagine removing all of those, and replacing them with the top
eleven bugs listed at
<https://bugs.launchpad.net/ubuntu/+source/software-center>.

If your response would be "But that would remove bugs that we really
need to fix for 12.10!", then we're kidding ourselves about their
Importance value, aren't we? Or about the importance of those bugs
currently marked High. Or about both. Either way, it would mean triage
is a waste of time.

On the other hand, if your response would be "Sure, that would be
fine", then linking bugs to the blueprint at all is redundant, except
as a way of making them show up on burndown charts. We might as well
just use the bug list -- after completing work items, fix as many
important bugs as possible, instead of letting the burndown charts
lull us into following Parkinson's Law.

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

iEYEARECAAYFAk/KTGIACgkQ6PUxNfU6ecrliwCfZuzBGFNMtkh5BfxcN2XGPxKv
rqEAmgKmHc93PrmR3dnuYsPWhyQuHmL+
=qXPe
-----END PGP SIGNATURE-----