Rethinking UDS

[Matt Zimmerman]

After each UDS, the organizers evaluate the event and consider how it could
be further improved in the future.  As a result of this process, the format
of UDS has evolved considerably, as it has grown from a smallish informal
gathering to a highly structured matrix of hundreds of 45-to-60-minute
sessions with sophisticated audiovisual facilities.

If you participated in UDS 10.10 (locally or online), you have hopefully
already completed the online survey at
http://www.surveymonkey.com/s/UDSMaverick, which is an important part of
this evaluation process.

A survey can't tell the whole story, though, so I would also like to start a
more free-form discussion here among Ubuntu developers as well.  I have some
thoughts I'd like to share, and I'm interested in your perspectives as well.

== Purpose ==

The core purpose of UDS has always been to help Ubuntu developers to
explore, refine and share their plans for the subsequent release.  It has
expanded over the years to include all kinds of contributors, not only
developers, but the principle remains the same.

We arrive at UDS with goals, desires and ideas, and leave with a plan of
action which guides our work for the rest of the cycle.

== The status quo ==

UDS looks like this:

http://mdzlog.files.wordpress.com/2010/05/screenshot-uds-m-schedule.png

This screenshot is only 1600x1200, so there are another 5 columns off the
right edge of the screen for a total of 18 rooms.  With 7 time slots per day
over 5 days, there are over 500 blocks in the schedule grid.  9 tracks are
scattered over the grid.  We produce hundreds of blueprints representing
projects we would like to work on.

It is an impressive achievement to pull this event together every six
months, and the organizers work very hard at it.  We accomplish a great deal
at every UDS, and should feel good about that.  We must also constantly
evaluate how well it is working, and make adjustments to accommodate growth
and change in the project.

== How did we get here? ==

(this is all from memory, but it should be sufficiently accurate to have
this discussion)

In the beginning, before it was even called UDS, we worked from a rough
agenda, adding items as they came up, and ticking them off as we finished
talking about them.  Ad hoc methods worked pretty well at this scale.

As the event grew, and we held more and more discussions in parallel, it was
hard to keep track of who was where, and we started to run into contention.
Ubuntu and Launchpad were planning their upcoming work together at the same
time.  One group would be discussing topic A, and find that they needed the
participation of person X, who was already involved in another discussion on
topic B.  The A group would either block, or go ahead without the benefit of
person X, neither of which was seen to be very effective.  By the end of the
week, everyone was mentally and physically exhausted, and many were ill.

As a result, we decided to adopt a schedule grid, and ensure that nobody was
expected to be in two places at once.  Our productivity depended on getting
precisely the right people face to face to tackle the technical challenges
we faced.  This meant deciding in advance who should be present in each
session, and laying out the schedule to satisfy these constraints.  New
sessions were being added all the time, so the UDS organizers would stay up
late at night during the event, creating the schedule grid for the next day.
In the morning, over breakfast, everyone would tell them about errors, and
request revisions to the schedule.  Revisions to the schedule were painful,
because we had to re-check all of the constraints by hand.

So, in the geek spirit, we developed a program which would read in the
constraints and generate an error-free schedule.  The UDS organizers ran
this at the end of each day during the event, checked it over, and posted
it.  In the morning, over breakfast, everyone would tell them about
constraints they hadn't been aware of, and request revisions to the
schedule.  Revisions to the schedule were painful, because a single changed
constraint would completely rearrange the schedule.  People found themselves
running all over the place to different rooms throughout the day, as they
were scheduled into many different meetings back-to-back.

At around this point, UDS had become too big, and had too many constraints,
to plan on the fly (unconference style).  We resolved to plan more in
advance, and agree on the scheduling constraints ahead of time.  We divided
the event into tracks, and placed each track in its own room.  Most
participants could stay in one place throughout the day, taking part in a
series of related meetings except where they were specifically needed in an
adjacent track.  We created the schedule through a combination of manual and
automatic methods, so that scheduling constraints could be checked quickly,
but a human could decide how to resolve conflicts.  There was time to review
the schedule before the start of the event, to identify and fix problems.
Revisions to the schedule during the event were fewer and less painful.  We
added keynote presentations, to provide opportunities to communicate
important information to everyone, and ease back into meetings after lunch.
Everyone was still exhausted and/or ill, and tiredness took its toll on the
quality of discussion, particularly toward the end of the week.

Concerns were raised that people weren't participating enough, and might
stay on in the same room passively when they might be better able to
contribute to a different session happening elsewhere.  As a result, the
schedule was randomly rearranged so that related sessions would not be held
in the same room, and everyone would get up and move at the end of each
hour.

This brings us roughly to where things stand today.

== Problems with the status quo ==

1. UDS is big and complex.  Creating and maintaining the schedule is a lot
of work in itself, and this large format requires a large venue, which in
turn requires more planning and logistical work (not to mention cost).  This
is only worthwhile if we get proportionally more benefit out of the event
itself.

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

3. UDS is (still) exhausting.  While we should work hard, and a level of
intensity helps to energize us, I think it's a bit too much.  Sessions later
in the week are substantially more sluggish than early on, and don't get the
full benefit of the minds we've brought together.  I believe that such an
intense format does not suit the type of work being done at the event, which
should be more creative and energetic.

4. The format of UDS is optimized for short discussions (as many as we can
fit into the grid).  This is good for many technical decisions, but does not
lend itself as well to generating new ideas, deeply exploring a topic,
building broad consensus or tackling "big picture" issues facing the
project.  These deeper problems sometimes require more time.  They also
benefit tremendously from face-to-face interaction, so UDS is our best
opportunity to work on them, and we should take advantage of it.

5. UDS sessions aim for the *minimum* level of participation necessary, so
that we can carry on many sessions in parallel: we ask, "who do we *need* in
order to discuss this topic?"  This is appropriate for many meetings.
However, some would benefit greatly from broader participation, especially
from multiple teams.  We don't always know in advance where a transformative
idea will come from, and having more points of view represented would be
valuable for many UDS topics.

6. UDS only happens once per cycle, but design and planning need to continue
throughout the cycle.  We can't design everything up front, and there is a
lot of information we don't have at the beginning.  We should aim to use our
time at UDS to greatest effect, but also make time to continue this work
during the development cycle.  "design a little, build a little, test a
little, fly a little"

== Proposals ==

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.

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.

C. Organize for cross-team participation, rather than dividing teams into
tracks.  A given session may relate to a Desktop Edition *feature*, but
depends on contributions from more than just the Desktop *Team*.  There is a
lot of design going on at UDS outside of the "Design" track.  By working
together to achieve common goals, we can more easily anticipate problems,
benefit from diverse points of view, and help each other more throughout the
cycle.

D. Build in opportunities to work on deeper problems, during longer blocks
of time.  As a platform, Ubuntu exists within a complex ecosystem, and we
need to spend time together understanding where we are and where we are
going.  As a project, we have grown rapidly, and need to regularly evaluate
how we are working and how we can improve.  This means considering more than
just blueprints, and sometimes taking more than an hour to cover a topic.

-- 
 - mdz