On 12/02/2010 02:42 PM, Ted Gould wrote: > On Thu, 2010-12-02 at 11:36 -0800, Jono Bacon wrote: > >> * Tracks - some of the feedback received was that the tracks at >> the last UDS were confusing and complex. What did you folks >> think of the tracks? One suggestion is that we ditch tracks and >> instead just have 'tags' for sessions (e.g. you add a session >> and tag it from a limited set of tags). Do you think this would >> be a better approach? >> > <snip> > >> * Track Leads - there seemed to be some confusion surrounding the >> expectations and responsibilities of track leads. How do you >> feel track leads could be most effective in helping the UDS >> experience? >> > I think these are related. One thing that I think was lost with this > UDS was a sense of "ownership" of a particular track. I felt like > before the track leads knew what was on their track, and why it was > there. This created a certain amount of continuity. > > What I think happened is that the number of sessions got overwhelming > for the track leads, there was no way to keep up. Which is true. > > So what I'd propose is have a set of "focused tracks" where there is > strong leadership from the track leads. And then have a set of > un-tracks that are loosely aligned, but allow for the breadth of > materials that UDS covers. > > --Ted > >
Hey Jono, I've always found that there there were a few things that could improve UDS, making the experience more enjoyable and productive. I'm of the opinion that we could benefit from less tracks (and time spent running around checking schedules). There are often multiple tracks I wanted to attend at the same time. Overlap of common subjects (in my case Desktop, QA and Multimedia subjects) cause conflicts, and mid-session parting/joining. I think we should allow people to discuss, demonstrate and code in an environment with less emphasis on time restrictions and more emphasis on team building. We can take much more time getting to know each other and forging trust and relationships. When "schmoozing" useful information gets passed, relationships get built and all this outside of these sessions. Perhaps theres something to learn from this. I'd also like to see better blueprints, clearly outlining what will be discussed and what we want to take away from a session. From what I understand, the choice to accept a blueprint is not one of the community, but of the track lead. I think we should make this more democratic. Many blueprints were close to empty leaving me wondering about the details to be discussed. It is important to set goals, discussions and decisions relative to the subject being discussed. I was once told that blueprints are to be filled in *after* the UDS session, however, I think the goals should be set before the session and final decisions/actions after the session. Cheers, -komputes (]( -. .- )[) -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
