Rethinking UDS

[Matthew Paul Thomas]

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

Bryce Harrington wrote on 28/05/10 04:30:
>
> On Thu, May 27, 2010 at 02:50:20PM +0100, Matt Zimmerman wrote:
>>
>> 2. UDS produces many more blueprints than we need for a cycle.  While
>> some of these represent an explicit decision not to pursue a project,
>> most of them are set aside simply because we can't fit them in.  We
>> have the capacity to implement over 100 blueprints per cycle, but we
>> have *thousands* of blueprints registered today.  We finished less
>> than half of the blueprints we registered for 10.04.  This means that
>> we're spending a lot of time at UDS talking about things which can't
>> get done that cycle (and may never get done).
>
> I think part of the reason there are so many blueprints is that they've
> kind of been advertised as akin to a feature wishlist, so a lot of
> random junk that never got discussed at any UDS is in there, and mostly
> isn't appropriate to keep around.

This is conflating two separate issues, I think.

One issue is that people register blueprints without ever doing the
specification work. They're analogous to Incomplete bug reports.

> If you think having too many "dead" blueprints registered is
> problematic, would you be open to the idea of doing some sort of
> bulk-expire on all the old ones that never got assigned / prioritized /
> targeted?  Just for the sake of de-crufting.

Launchpad Bugs already handles this: if a bug report stays Incomplete
for long enough, it automatically expires. Feature specifications could
be treated in exactly the same way (and, I've long proposed, in exactly
the same tracker). The difference would be that for a bug report, the
reporter is responsible for reproducibly specifying the *problem* or
finding people who can; for a feature request, the proposer is
responsible for specifying the *solution* or finding people who can.

The other issue is that people fully specify features, and get them
approved, without having time or people ready to implement them. UDS is
a major cause of this, because it implies that features for a release
should be planned and specified in a brief window five months before
that release. This wastes time in specifying features that later get
dropped, or that need to be re-specified later because the architecture
or environment has changed. (I have multiple recent experiences of this:
months ago I wrote a network menu specification that will now need heavy
revision because UNE is switching from NetworkManager to
ConnectionManager, and a battery status menu specification that probably
will need heavy revision before it's ever implemented because
gnome-power-manager is undergoing architectural changes.)

I think the solution to this is to not specify features until you are
ready to start implementing them. This would mean UDS would be less
about designing every feature for the next release, and more about
architecture plans, process improvements, brainstorming, sketchboarding,
and other types of discussion that need really high bandwidth.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv/kY8ACgkQ6PUxNfU6ecpejgCgkIj06Elc/cfb3iNzJXczinCg
u4kAnAv43Tp78pFg1xeV9MTNFazjbS9r
=E6lN
-----END PGP SIGNATURE-----