Improving UDS

[komputes]

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

  (]( -. .- )[)