Rethinking UDS

[Matt Zimmerman]

On Thu, May 27, 2010 at 08:53:31PM -0400, Jorge O. Castro wrote:
> On Thu, May 27, 2010 at 9:50 AM, Matt Zimmerman <mdz at ubuntu.com> wrote:
> > 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.

This seems consistent with my point #5 about how UDS isn't configured for
cross-team participation.  Hallway time is valuable, and I support the idea
of having substantial unscheduled time to let this happen, but it also
shouldn't be the only time that people run into their Ubuntu colleagues who
work on related stuff.

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

Agreed, I think we should reach out to both upstream developers and Debian
maintainers about what's happening at UDS.

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

Yes, this is a good example of my point #4, that the event is optimized for
short, self-contained discussions with a clear outcome and work items.  My
point is that there is important work to do which, in the context of a
blueprint and work items, might look like a "rabbit hole" but is nonetheless
important.

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

I think shortening or subdividing the event is worth exploring.

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

Agreed on all points.

> > 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"?

I think we already do say that, but we either overestimate what we can do,
or we feel the need to fill up the schedule grid with sessions.  Some teams
can finish a lot more work items than others (e.g.  because they're bigger),
but the schedule grid is the same size for each track.

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

Agreed.  I would also say that there are definitely people participating in
UDS who *should* get involved in these focused discussions, but may not have
the opportunity because they're scheduled into sessions all week.

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

I think that something similar to the kernel team's approach could work well
for other teams, especially QA, and to some extent community and
foundations.  For example, something I saw at UDS-M was that the QA team had
a bunch of sessions about testing, and then the development teams had their
own testing sessions, and the two were disconnected.  Instead, I'd like to
see sessions on testing a particular product or subsystem with
cross-participation from the QA team and the development team.

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

If we resolve the exhaustion problem, and we're only creating enough
blueprints to fill our capacity for the cycle, then I think there's room for
more content like this (and more ideation and other non-blueprint or
not-yet-blueprint work) at UDS.

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

Agreed.

> Plenaries - I would like to limit these to 15 minutes from now on.
> From my vantage point I can see people spacing out when they get too
> long. Alan Bell and Alan Pope recommended that we should consider
> lightning talks at the /beginning/ of UDS, not for random talks but
> where people kind of "sell" their session later in the week - this
> could help getting people to where they need to go. Also I like the
> discussion that can be generated from lightning talks.

I'd like to see the first day at UDS include a thorough introduction to the
key themes for the cycle, both on the client and server, and then have
corresponding groups of sessions on Tuesday and Wednesday, or something
along those lines.  I'd also like to see more time spent at the beginning of
UDS on retrospectives, to evaluate how well we did during the cycle and
agree on improvements to make in the upcoming cycle.  This is a good way to
set the stage for blueprint work.

> Scheduling - I've already proposed that someone at the desk should be
> able to schedule sessions, that will remove the "find Jorge or an
> orange shirt or you'll never get things scheduled" problem.

I think people should be able to schedule things themselves, e.g. on a
whiteboard. :-)

-- 
 - mdz