Rethinking UDS

[Jamie Bennett]

On Thu, 2010-05-27 at 14:50 +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).

This is the point that really hits home. We are spending time pre-UDS
exploring, researching and discussing blueprints that either will never
happen or won't happen for another 6-12 months. Post UDS we are
triaging, expanding and sometimes dropping blueprints, this is far from
optimal and in some cases disappointing.

> A. Concentrate on the projects we can complete in the upcoming cycle.  If we
> aren't going to have time to implement something until the next cycle, the
> blueprint can usually be deferred to the next cycle as well.  By producing
> only moderately more blueprints than we need, we can reduce the complexity
> of the event, avoid waste, prepare better, and put most of our energy into
> the blueprints we intend to use in the near future.

This would be a great help. There were many times this UDS where I
wanted to be in 'two places at once'. Reducing the number of blueprints
and hence the number of sessions will be a great help in bringing down
these conflicts.

> B. Group related sessions into clusters, and work on them together, with a
> similar group of people.  By switching context less often, we can more
> easily stay engaged, get less fatigued, and make meaningful connections
> between related topics.

Again, great idea. If one has to run between rooms every hour, sometimes
over different floors, its not at all productive.

>  - mdz

Regards,
Jamie.