Rethinking UDS

[Robbie Williamson]

On Thu, 2010-05-27 at 14:50 +0100, Matt Zimmerman wrote:
[snip] 
> == 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.
Sometimes the simple answer is the best...cap the number of blueprints
that can be accepted into to a given release.  If we estimate capacity
to be 100 blueprints per cycle, then set the cap at 120 to also allow
for discussion of things we might do, in case we decide not to do
something else.

> 
> 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 think we have too many concurrent sessions.  In looking at UDS 10.10,
there was a potential to have 18 sessions going on at the same time.
That's 126 sessions in one day...576 sessions in a week!  Obviously, we
don't have to fill the schedule to capacity, but a schedule with too
many holes in it sucks too, imo.  We need to trim this down.

> 
> 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.
In the 4 UDSs I've attended, the sessions have been put into tracks
based on the Canonical teams involved in Ubuntu development: Kernel,
Foundations, Desktop, Server, Mobile, QA, Security and Community...and
we rightly added Design recently. It seems to me that we would be better
off organizing around products or themes.  We could have tracks per
product, Desktop and Server, but then I think the track concept becomes
meaningless.  I think going by themes is the best approach, as for each
release there are some, e.g. Boot Performance, Social from the Start,
Ubuntu on ARM, Desktop User Experience, Cloud Computing, Server
Workloads, etc. We should set a fixed number of themes, say 8, and based
on that, a fixed number of tracks, like 10.  The 2 additional tracks are
to allow for a "theme-less" track (to cover items that need discussion,
but don't really fit) and a "Brainstorm" track, where we schedule those
"OMG, we need a session on this!" sessions that always come up while at
UDS. This track should default to 30min slots, not an hour.

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

I don't see this as something we can't do now.  You can schedule
sessions over multiple blocks, so if a topic needs 2 hours...schedule 2
hours.  I think the bigger problem is making sure we don't schedule
discussions that need less than an hour...if it only needs 30min, it
should probably be done over the phone, irc, a public ubuntu.com mumble
setup, and/or email, imo.


-- 
Robbie Williamson                                     robbie at ubuntu.com
Ubuntu                                         robbiew[irc.freenode.net]                               

"You can't be lucky all the time, but you can be smart everyday" 
 -Mos Def

"Arrogance is thinking you are better than everyone else, while
Confidence is knowing no one else is better than you." -Me ;)