Rethinking UDS

[Jorge O. Castro]

On Thu, May 27, 2010 at 9:50 AM, Matt Zimmerman <mdz at ubuntu.com> wrote:
> 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.

Thanks for bringing this up, I think there are a bunch of low hanging
fruit that we can fix with a post-UDS thread on -devel. I've helped
plan every UDS for the past three years (and started to scale back
this UDS so I can concentrate on attending); and I've attended an
early one (for Hoary) and the first Mountain View, so I've been
fortunate to see the event evolve and I have some feedback:

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

At first I thought the idea of switching around rooms after each
session wasn't a good idea, but I've found that getting people out in
the hallways is valuable, a great deal of important work and
discussion happens outside the sessions and outside the normal hours
during social events. However there's no reason we couldn't have kept
tracks in a general vicinity, so as to force people to intermingle,
but maybe only once a day but "keep these tracks on these floors" for
example. Alternating the ARM folks between the two big rooms I think
would have been a better solution than the seemingly random bits
perhaps.

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

Feedback from new first-time upstreams and Debian people (who perhaps
might be there opportunistically as opposed to planning on attending)
confirms to me that it's too complicated.  In the past when we were
smaller a track lead used to just tell me "hey we're talking mp3
players at this discussion, can you see if these people can attend
remotely?" but these days it's too big for just one person to be able
to make this happen. On your blog a Debian packager responds with "
I’ve not known, that the UDS will take place and that Hadoop, HBase
and Zookeeper will be discussed there. Since I was on IRC, Torsten
Werner was able to ask me two questions during the session.  However,
the the audio recording of the session revealed, that I could have
answered many more questions if I’d only have been asked."

I think perhaps overall when we're planning sessions we (we being the
person running the session and making the blueprint) should at least
make an attempt to invite the proper upstream and/or Debian person to
participate. The Nautilus improvements session was really great, but
we had _zero_ participation from anyone upstream because no one
communicated that we were talking about improving Nautilus at UDS. Had
I know ahead of time maybe we could have done a better job.

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

On Thursday Jono mentioned something in our track, something like "If
it's 20 minutes left in a session and we don't have the BP open and
assigning work items and what we're doing for Maverick then we're
probably going down a rabbit hole". Though I can totally understand
that some sessions require multiple discussions.

Looking at uds-m we had 5 sessions talking about LoCo teams (though
this can apply towards any topic I am sure). That's _five_ hours of
Loco Teams. Maybe we should go lean and mean: 3 days for UDS. By
Wednesday my cycle was already full!

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

Since I am not involved in planning UDS as much this cycle I got the
opportunity to participate in a bunch of sessions I normally wouldn't
have so I took the opportunity to explore a bit. I like the way the
kernel team does their "service based" approach. They still had a
track but sent representative to other tracks; perhaps not having such
a strict track-based approach would help here. At one point one of
them grabbed me in the hallway and said "we need some community folks
in our track for like 10 minutes, can you guys drop by?" and then
Matthew Helmke and I were able to address some concerns they had and
take away some things to fix for their team. This way you don't feel
like "I am a specialist at foo, therefore I should stick to foo
track."

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

I think this can be solved by reiterating that UDS is for "this next
cycle" when we start and when we start each session. Sometimes I come
to UDS with these great awesome ideas, but we all come up with ideas
all the time, UDS should be how we plan on implementing ideas and
maybe not so much about brainstorming. Perhaps "less brainstormy, more
sprint"?

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

I will be upfront and say I "cheat" here. I've pulled people aside for
multiple-session slots, grabbed a private corner with someone, pulled
people out of sessions to go to other sessions, etc. I like the
flexibility we have here. You could easily guess "those people have
been sitting next to the dessert tray for two hours, they must not be
participating" but I've always found that people do this to
concentrate on something specific without context switching.

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

Indeed the kernel team's approach to this seems successful to me,
maybe someone from that team can give us some feedback on how that's
worked out for them.

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

Since we're brainstorming here let me also take these items off my chest:

Length - I've always wanted to propose a "debcamp" like few days after
UDS so people can get real sprint-like things done, but who wants to
be the person to propose a longer UDS? 3 days of planning and 2 days
of sprinting could fix that though. By Wednesday I am ready for the
rest of the cycle. You can so tell that on Thursday and Friday people
are basically saying "yeah whatever, assign me the work item and I
will look at it when I get home, just subscribe me to whatever." Then
you get home, line them all up and drop the bottom half.

Location of UDS - everything about our release cycle is predictable
except where/when we plan the distro. Let's pick 2 places in the
Americas, and 2 in Europe and rotate. We go with known-good hotels
that have served us well in the past, and it gives an opportunity for
our partners and upstreams to know where we're going to be way ahead
of time. I can think of two people who couldn't come to UDS because
the Visa window was just too short. This would also allow for more
non-Ubuntu participation from people who wouldn't normally be able to
come to an event.

Plenaries - I would like to limit these to 15 minutes from now on.