Fedora Events FAD - Days 0-1

| 1 Comment | No TrackBacks
So I'm in Raleigh for the Fedora Events FAD, had an interesting time getting here - I had some things to do earlier in the day before I left in the evening for the FAD, so I got home maybe an hour before I had to leave for the airport, and had nothing packed or prepared for it; Typical late planning me. So I got home maybe an hour before I had to leave for the airport (took the E train to the Airtrain). I figured that with all of the increased security and whatever, it would take me forever and a day to get through security.  Not the case - flew right through and there was nobody at JFK. You would think that for having such low volume all of the flights would be on time, but it would seem that's not the case  we were delayed somewhere around 90 minutes getting out of JFK to come to Raleigh because of some weather in Montreal apparently. Got here and Mel Chua picked me and Dennis Gilmore up from the airport and went back to the hotel.

This morning, we were at the Red Hat offices bright and early, and got to work. Most of our work from today has been captured on the wiki, but I figured that I'd go into a few highlights of what I thought was most important.

We started out the day with four basic questions, and everyone put post-it notes on the whiteboard around that question. The four questions were what makes a good FUDCon, what makes a good FAD, what the difference was between a FAD and a FUDCon, and how to get stuff from point A to point B.

We only really got to the first of those four questions today, and by far, the item that makes a FUDCon most successful is ponies. But Paul threw that one out right at the beginning!

Seriously, we came up with some great ideas of what makes a FUDCon successful, and split that up into several distinct action items that we are going to further define tomorrow - they can also be found on the wiki, but I'll hit what I thought were to two most cogent things - what have we done right in the past that we want to preserve for future FUDCon's - in other words, what are the requirements to hold a successful FUDCon, and what things would we like to see change in the future about the event. 

We then reviewed the presentation done by the awesome marketing team of the results of the survey from Toronto, and wrote down the recurring themes that we saw from that on the other side of the whiteboard. Then we began the process of taking things from the post-it side of the board where we laid out "what makes a good FUDCon" and aligned those things with the feedback topics, mostly around the "things we want to keep that are required for a successful FUDCon", and "things that we would like to change at future FUDCon's" 

We came up with a number of things in both camps, but I figured that I would touch on one that's probably not reflected on the wiki, but was captured in a video that Mel is posting somewhere.

The discussion centered around four things that wound up on the board - really they were just different ways of stating two opposite things - more planning sessions and less planning sessions. I think that both ideas are important, and I think that we came to some understanding as to how to achieve all of the goals at the same time. . We debated things going both ways, and what I think we walked away from that conversation with is that while both types of hackfests are important, they each have different goals, and the FUDCon hackfests that we have today generally could use improvement on the former category - for instance, for the Fedora Talk FAD that we had in Fredricksburg, going into the FAD we knew exactly what we wanted to have accomplished coming out of the FAD, and had some measure on how to judge that as a success or failure. We don't have the same accountability for a hackfest at FUDCon. With so much debate going back and forth, we eventually came to the conclusion that while nothing is "broken" about the current hackfest process, however, we could do a better job of encoruaging planning going into the hackfest so that a defined set of goals is laid out prior to the hackfest (where that goal could be simply having a design for the "brainstorming" type of hackfest to having X, Y, and Z features implemented for the pre-planned type of hackfest) that we can objectively measure the success or failure of the hackfest against.

We then went to focus our efforts on capturing these items (and others that we came up with while doing so) on the wiki.

All in all, there will be 7 items that we hope to knock out tomorrow:

  1. Generic FUDCon calendar - i.e what FUDCon happens in which region of the world around what time frame (generally aligned to Red Hat fiscal quarters)
  2. A specific instantiation of that calendar for 2010 - because we're already in 2010 talking about this, the 2010 one may differ slightly form the one going forward
  3. The bidding process for where to hold a FUDCon
  4. Things that we like about the current FUDCon, and what is required in order to make a FUDCon a success - a minimum level of infrastructure, people, etc.
  5. What would we change about FUDCon, and what specific problem area that we identified does that either definitely or perhaps solve
  6. A "FUDCon organizer HOWTO guide"
  7. Clearly defined process and standards around attendee sponsorship
I think that I've rambled enough for one blog post :)
Reblog this post [with Zemanta]

No TrackBacks

TrackBack URL: http://blog.jds2001.org/cgi-bin/mt-tb.cgi/359

1 Comment

Life is not a pony farm! ;-)

Leave a comment