Rethinking UDS

Pete Graner pgraner at canonical.com
Fri May 28 22:01:31 BST 2010


On Fri, 2010-05-28 at 09:47 +0100, Matt Zimmerman wrote:
> On Thu, May 27, 2010 at 08:53:31PM -0400, Jorge O. Castro wrote:


Snip....

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

The kernel team has been experimenting with various ways to make UDS
effective for our team over the last two cycles. I thought I'd share
what we do and why in case it might help other teams.

The kernel team uses a service model to support the other development
teams. We derive over 80% of our work items from other teams needs. So
rather than have dedicated kernel tracks we've taken a hybrid approach.

Mon-Wed the kernel team separates out to cover all the other tracks the
might need kernel input.

Thru-Fri we run mostly dedicated kernel tracks, for things that we need
to decide on, plan, or discuss. We still send people out to other
sessions if needed. But during these days we try and stay single
threaded and not run multiple sessions at the same time.

The key to making all of UDS successful for us is the morning Kernel
Team Roundtable.

The first session of every day we get the entire team together and do a
few important things.

1. We go over the schedule from the day prior. Any one that went to a
session will get up and discuss what happened and fill out the gobby doc
with the notes that pertain to the kernel team. This allows for
knowledge sharing among the team and broader team discussion.

2. We go over the current days schedule and figure who is going to cover
what sessions.

3. We cover and admin items, session conflicts and the like as well.

We have found these simple things have made our UDS far more productive.

Hope it helps.

~pete





More information about the ubuntu-devel mailing list