Rethinking UDS

[scott at kitterman.com]

I've attended five of the the last six UDS. I can attest to the recent growth in the complexity and scale of the event.

I completely agree about the need for more retrospection we've had a couple of lessons learned sessions for foundations (Barcelona and Brussels) that I think have been valuable. I would like to see this applied more broadly.

I find that the most valuable sessions are the ones that have a mix of people from heterogeneous groups. Having the same people who work together throughout the cycle in a session is rarely interesting nor does it produce results that couldn't have been gotten without a UDS.  The best are often the found moments where someone completely unexpected gets connected to a discussion and provides a different way of considering a problem. 

Changes that impact multiple teams are another area that UDS is essential for. The sessions on getting new apps in post-release comes to mind from UDS-M.

I have been fortunate to be at UDS as a community developer.  I think it's fortunate because I'm not bound to the requirements of a defined job description or a team with a boss making specific demands on my time. As a result, I was able to attend a diverse set of sessions. I have a sense that more people doing this would make UDS better. 

I don't know that the total number of sessions or specs is a problem,  but I do find the schedule is a bit front loaded. At UDS-M, I found on the first two days there was an average of about 1.5 sessions per block that I really wanted to attend.  On the last two days it was about 0.8.  If sessions that might be broadly interesting,  but are unlikely to need follow-up were pushed more towards the end of the week, the overall intensity of the week might be reduced without getting less done.

I think ogra's point about community input is important and also relates to why there are so many specs that never get implemented. People seem to think that getting a spec approved will cause resources to appear to implement it. As a community developer,  I think specs are important for only a few reasons: 

 - Work needs to be coordinated among several developers 

 - Work requires Canonical resources (e.g. moving packages into Main or changes ISO build and test requirements)

Beyond that, I don't feel a need for specs and someone else writing a spec is extremely unlikely on it's own to convince me to work on something. 

For Canonical,  I think specs can serve as a mechanism to communicate their development plans to the community and to solicit community involvement and support. 

Somehow we need to narrow the spec writing audience so we don't have the continuing flood of specs that no one will implement.  Ideally,  Brainstorm would be a part of Launchpad and Blueprints would be used as just part of the development process and not as an input. 

In addition to more retrospection,  I think we could use more long term thinking. We did have some discussions at UDS-M around what the next LTS might look like,  but I think more longer term thinking is good to help clarify what should be done now (as an example,  the Kubuntu team has decided to switch to pulseaudio by default in this cycle to make sure we have it nailed for the next LTS).

Scott K

P.S. Sorry if it rambles a bit.  I've been writing this a little bit at a time over the last several days as I've had time.
ubuntu at kitterman.com